Application Protection

Access Restriction

#Application Protection #Add-ons

Sets up a filter in nevisProxy to block or filter incoming requests based on the source IP of the request.

The pattern can be assigned to applications or an entire Virtual Host using Additional Settings.

Blocked requests are responded to with HTTP error code 403.

To produce a nice looking error page, ensure that you have configured an error page for 403 on the Virtual Host or use the HTTP Error Handling pattern on the same location.

Source IPs accepts individual IPv4 addresses and ranges in the form 192.0.2.1-192.0.2.255. Deferred endpoints are also supported, for example placeholder://from_1 - placeholder://to_1, and may be mixed with concrete endpoints. Deferred values remain quoted in the generated Lua and must resolve to valid IPv4 addresses during deployment; unresolved or invalid values fail closed. IPv4 CIDR notation remains supported for individual concrete entries.

Listing Type

Indicates if Source IPs should be used as blacklist or whitelist.

blacklist: Access from all configured Source IPs is denied. All other IPs are allowed.
whitelist: Access is allowed only for IPs in the Source IPs list. All other IPs are blocked.

Source IPs

List of client source IPs which shall be allowed. You may include entire range of IPs by separating two IPs with -. If there is load-balancer in front of nevisProxy please configure it to preserve the client source IP. IPv6 is not supported here.

Examples:

10.0.0.1: specific IP address
192.168.0.0-192.168.0.255: range of IP addresses
0.0.0.0-255.255.255.255: all IP addresses

Source IP HTTP-Header

Optional setting used to specify HTTP header that contains the users IP. Otherwise, a default environment variable from nevisProxy is used.

Examples:

X-Forwarded-For

Country Database File

IP geolocation database file for country filtering.

Currently only the mmdb format (MaxMind Database) is supported. This is a binary file format.

Country Database URL

IP geolocation database URL for country filtering.

The resource behind the given URL is periodically downloaded and used as an IP geolocation database. Currently only the mmdb format (MaxMind Database) is supported. This is a binary file format. Using dbUrl and dbFile together is not supported, only set one of them.

Rules

Defines what action should be taken for a specified country.

Possible actions are:

allow: Requests are let through
log: A log entry is made for each request from the specified country
block: Blocks requests from a country

Default Action

Defines the action taken either when no country rules were matched or the IP of a request does not have an associated country in the database.

Possible actions are:

allow: Requests are let through
log: A log entry is made for each request
block: Blocks requests

Apply only to sub-paths

Set to apply this pattern on some sub-paths only.

Sub-paths must be relative (e.g. not starting with /) and will be appended to the frontend path(s) of the virtual host (/) or applications this pattern is assigned to.

Sub-paths ending with / are treated as a prefix, otherwise an exact filter-mapping will be created.

The following table provides examples to illustrate the behavior:

Frontend Path	Sub-Path	Effective Filter Mapping
`/`	`secure/`	`/secure/*`
`/`	`accounts`	`/accounts`
`/`	`api/secure/`	`/api/secure/*`
`/`	`api/accounts`	`/api/accounts`
`/app/`	`secure/`	`/app/secure/*`
`/app/`	`accounts`	`/app/accounts`
`/app/`	`api/secure/`	`/app/api/secure/*`
`/app/`	`api/accounts`	`/app/api/accounts`

Allow Override

By default, access restriction rules apply to all sub-locations.

For instance, when you assign an Access Restriction pattern to a Virtual Host all applications on this virtual host will be affected.

To replace the rules defined on a parent location select enabled on all Access Restriction patterns in the hierarchy.

If disabled is selected anywhere in the hierarchy the rules are considered additional.

Technical Details:

This feature is implemented using a nevisProxy LuaFilter. Mapped filters are inherited to sub-locations unless an exclude-url-regex is defined.

By selecting enabled the generator is informed that the mapped filter has the purpose access restriction. The generator then ensures that an exclude-url-regex entry is generated when a filter with the same purpose is mapped to a sub-location.

Custom GeoLocation Lookups

The geolocation database contains multiple attributes to its IP-groups. The attribute(s) that are retrieved by an IP-lookup can be altered using this parameter. To check what attributes are in your database, use the tool mmdbinspect. To set a path, separate its elements by slashes (/). Each lookup entry contains a path as key and an output variable name as value. This output variable makes the returned entries accessible from LuaFilter with req:getAttribute('output_var').

Examples:

country/names/en➜geolocation: Uses the country's English name and sets the geolocation request attribute.
country/iso_code➜countrycode: Uses the country's two letter long code and sets the countrycode request attribute.
country/names/en➜geolocation, country/iso_code➜countrycode, continent/code➜continentcode Keep the default country name but also set the country code and continent code.

By default, the country's English name is used.

Country Database Download Periodicity

The IP geolocation database download periodicity. Only has effect when the database URL is set.

#Application Protection #Add-ons

Configure whether cookies are to be returned to the caller or stored in the user session.

You may also assign the pattern to multiple applications, and set Shared Protected Cookies to share cookies between applications.

Note that cookie sharing is supported only for applications using the same session in nevisProxy, that is, applications protected by the same authentication realm.

The default cookie handling differs based on the type of application:

| Type | Behaviour | |---|---|---| | Web Application (with authentication) | Cookies are stored. | | Web Application (public) | Cookies are allowed to passthrough. | | REST API | Cookies are dropped. | | SOAP Service | Cookies are dropped. |

Client Cookies

Cookies listed here will be allowed to pass through.

Use for cookies which should be returned to the caller (e.g. browser).

Regular expressions are supported.

Example:

LANG.*

Shared Protected Cookies

Cookies listed here will be stored in nevisProxy and shared between all applications which have this pattern assigned.

Note that storing cookies requires a user session. Thus, we recommend not using this feature for applications which are supposed to be stateless and public.

Regular expressions are supported.

Note that cookies matching ^Marker_.*$ will never be stored as a corresponding allow rule is generated to support Session Expiration features of the SAML SP Realm.

Example:

LANG.*

Protected Cookies

Cookies listed here will be stored in nevisProxy.

However, cookies marked as Client Cookies in any Cookie Customization pattern assigned to the same application will still be allowed to pass through!

Storing cookies requires a user session. Thus, we recommend not using this feature for stateless or public applications!

Incoming cookies with the same name will be blocked.

Regular expressions are supported.

Example:

.*SESSION.*

When multiple Cookie Customization patterns are used it happen that a certain cookie is defined as both a Client Cookie and as a Shared Protected Cookie for the same application.

By default, this conflict is resolved by allowing the cookie to pass-through, treating it as a Client Cookie.

This behavior is usually more robust but less secure as the cookie will be accessible in the browser.

Select protect to threat the cookie as a Shared Protected Cookie instead.

CSRF Protection Settings

#Application Protection #Add-ons

Customize CSRF protection for an application, for example, Web Application.

You can assign the pattern to Virtual Host patterns as well, to configure CSRF protection for all applications on this host.

Set to lax to issue a separate cookie with the SameSite flag set to lax. In this configuration, links and redirects from other domains are allowed, while CSRF-prone requests (e.g. POST) should be prevented by the browser.

Set to off to not send an additional cookie. There are several reasons why this feature may be disabled:

Not all browsers support the SameSite flag and behave incorrectly by never sending the cookie. Older versions of IE and Windows may be affected.
The SameSite flag breaks SAML use cases when POST binding is used.

SP-initiated authentication does work with NEVIS but all other SAML process (e.g. logout) will fail.

Header-based Check

CSRF protection can be obstructive for some cross-domain use cases (e.g. federation or providing a public REST API).

Allowed Domains

CSRF protection can be obstructive for cross-domain use cases (e.g. federation or providing a public REST API).

Enter domains which should be excluded from header-based CSRF protection. There is no support for wildcards, pre- or postfix notations (sub-domains must be listed individually).

Example:

www.adnovum.ch
adnovum.ch

Generic Application Settings

#Application Protection #Generic

Customize the web.xml configuration for an application using XML constructs as described in the nevisProxy Technical Documentation.

Use as add-on for Web Application, SOAP Service, or REST Service.

The following expressions may be used for all applications:

${name}: sanitized name of the pattern
${service.name}: the name of the application
${service.id}: the unique ID of the application
${host.key}: use as EntryPointID when adding a custom IdentityCreationFilter (advanced use case)

For applications with only 1 Frontend Path:

${service.path}: the frontend path of the application, excluding trailing slash / and asterisk *
${service.mapping}: the url-pattern calculated for the frontend path of the application

In case an Authentication Realm is assigned:

${realm.name}: name of the realm (use for StateKey / DelegateSource)
${auth.connector}: name of the Esauth4ConnectorServlet (use for AuthenticationServlet)
${logrend.renderer}: name of the LoginRendererServlet
${logrend.connector}: name of the Http(s)ConnectorServlet for nevisLogrend (if nevisLogrend is used)

When defining filters it is recommended to set Filter Mappings to automatic. This way the filters are mapped to all frontend paths of the application.

Filters and Mappings

Configure filters and their mappings using the XML syntax described in the nevisProxy Technical Documentation.

Filters that have the same name as other filters (even those defined by other patterns) will be combined: the init-param sets will be merged where possible. Direct contradictions are interpreted as validation failures.

Example 1: Create (or patch) a filter with a fixed name

<filter>
   <filter-name>SomeName</filter-name>
   <filter-class>ch::nevis::isiweb4::filter::SomeClass</filter-class>
   <init-param>
      <param-name>...</param-name>
      <param-value>...</param-value>
   </init-param>
</filter>

Example 2: Create (or patch) a filter using an application-specific name

<filter>
   <filter-name>SomeName_${service.name}</filter-name>
   <filter-class>ch::nevis::isiweb4::filter::SomeClass</filter-class>
   ...
</filter>

Example 3: Map a filter to a sub-path of the assigned application(s). This example works for applications which have 1 frontend path only.

<filter-mapping>
   <filter-name>SomeFilter</filter-name>
   <url-pattern>${service.path}/custom/*</url-pattern>
</filter-mapping>

Example 4: Use multi-value expressions

Multi-value expressions replicate an entire line for each associated value.

Use the expressions *{service.path} and *{service.mapping} to generate filters which must contain the frontend paths of all assigned applications.

The following snippet is not complete but should illustrate the concept:

<filter>
    <filter-name>FormSigning</filter-name>
    <filter-class>ch::nevis::isiweb4::filter::validation::EncryptionFilter</filter-class>
    <init-param>
        <param-name>EntryURL</param-name>
        <param-value>
            *{service.path}/
        </param-value>
    </init-param>
    ...
</filter>

Filter Mappings

Choose between:

manual (default): only the filter-mapping elements which have been configured via Filters and Mappings will be added.
automatic: filters configured via Filters and Mappings will be mapped to all Frontend Paths of the application.
both: like automatic but additional filter-mapping elements are allowed as well.

Filter Phase

When adding filter-mapping elements, a phase must be defined.

The phase defines where the filter-mapping is placed in the web.xml and ensures that filters are applied in the right order, relative to other phases.

The order within a certain phase is undefined as it must not matter.

The order for requests is START to END and END to START for responses.

This setting applies to all filter-mapping elements.

The filter-mapping elements may be provided via Filters and Servlets, or created automatically (see Filter Mappings for details).

Choose from the following filter phases:

START: applied as early as possible for requests and as late as possible for responses.
BEFORE_SANITATION: applied before filters which validate the request (e.g. Mod Security).
SANITATION: used for security. This is the first phase which allows accessing the session for applications protected by a realm.
AFTER_SANITATION: your request has passed security checks.
BEFORE_AUTHENTICATION: applied just before authentication.
AUTHENTICATION: used by the filter which connects to nevisAuth for applications which are protected by an Authentication Realm.
AFTER_AUTHENTICATION: the request has level 1 authentication. Used by Authorization Policy for Authentication Level stepup.
BEFORE_AUTHORIZATION: choose this phase to do preprocessing before authorization.
AUTHORIZATION: used by Authorization Policy for Required Roles check.
AFTER_AUTHORIZATION: used by patterns assigned as Application Access Token to applications.
END: applied as late as possible for requests and as early as possible for responses.

This setting is ignored when you patch a filter generated by another pattern (e.g. by adding, overwriting, or removing an init-param element) but do not create any filter-mapping element.

Servlets and Mappings

Configure servlet and/or servlet-mapping elements using the XML constructs described in the nevisProxy Technical Documentation.

You may add new elements or customize elements provided by other patterns.

Reference a servlet by setting servlet-name. Use Connector_${service.name}for the servlet which connects to the backend application.
Reference a servlet-mapping by setting url-pattern.

In Kubernetes side-by-side deployment a postfix is added to service names. Use the expression ${service.postfix} connecting to a service deployed against the same inventory.

Example 1: Add or overwrite an init-param:

Enable load-balancing when there are multiple backend servers.

<servlet>
  <servlet-name>Connector_${service.name}</servlet-name>
  <init-param>
    <param-name>LoadBalancing</param-name>
    <param-value>true</param-value>
  </init-param>
</servlet>

Instruct nevisProxy to a add Content-Type header when missing.

<servlet>
  <servlet-name>Connector_${service.name}</servlet-name>
  <init-param>
    <param-name>ProxyPolicy</param-name>
    <param-value>mime-completion</param-value>
  </init-param>
</servlet>

Example 2: Remove an init-param (no param-value provided):

<servlet>
  <servlet-name>Connector_${service.name}</servlet-name>
  <init-param>
    <param-name>CookieManager</param-name>
  </init-param>
</servlet>

Example 3: Change the servlet-mapping for an application to use a different servlet by changing servlet-name.

<servlet>
   <servlet-name>Connector_Conditional_${service.name}</servlet-name>
   <servlet-class>ch::nevis::isiweb4::servlet::mapping::ServletMappingServlet</servlet-class>
   ...
</servlet>
<servlet-mapping>
   <servlet-name>Connector_Conditional_${service.name}</servlet-name>
   <url-pattern>${service.path}/*</url-pattern>
</servlet-mapping>

Removing servlet or servlet-mapping elements is not supported.

Template Parameters

Define Template Parameters.

Examples:

backend-host: backend.siven.ch

These parameters can be used in:

Servlets and Mappings
Filters and Mappings

The expression formats are:

${param.<name>}:

name found: parameter value is used.
name missing: expression is not replaced.

${param.<name>:<default value>}:

name found: parameter value is used.
name missing: default value will be used.

In <default value> the character } must be escaped as \}.

Remove Filter Mappings

Remove <filter-mapping> elements generated by other patterns.

The syntax is a map of <filter-name>:<url-pattern>, according to elements from the web.xml.

In the <filter-name> the expressions ${service.name} and ${realm.name} may be used.

For applications which have only 1 frontend path you may use ${service.mapping} instead of <url-pattern>.

Examples:

ModSecurity_${service.name}:${service.mapping}
Authentication_${realm.name}:${service.mapping}

Generic nevisProxy TLS Settings

#Application Protection #Add-ons

Use the add-on to customize TLS/SSL settings for nevisProxy.

Assign to a Virtual Host to customize settings for incoming connections.

You can customize connections to backends by assigning the pattern to your applications (Web Application, REST Service, SOAP Service) using Additional Settings.

Protocols

The value(s) configured here will be used as SSLProtocol. Read the Apache Documentation for supported values.

The SSLProtocol can appear in 2 different places, depending on where this pattern is assigned:

as attribute for the SSL element in navajo.xml.
as init-param for the HttpsConnectorServlet.

If nothing is configured, a default will apply. The default is determined as follows:

For the SSL element in navajo.xml the SSLProtocol attribute will be generated as -all +TLSv1.2 +TLSv1.3 by the Virtual Host pattern.
For the HttpsConnectorServlet no SSLProtocol init-param will be generated, and thus the default of this servlet applies. Read the documentation of the HttpsConnectorServlet for further information.

Cipher Suite

Configure the allowed cipher suites.

Read the Apache Documentation for the supported format.

The value configured here will be applied as:

SSLCipherSuite for the SSL element in navajo.xml when the pattern is assigned to a Virtual Host.
SSLCipherSuites for the HttpsConnectorServlet element in the web.xml when this pattern is assigned to an application.

If nothing is configured, a default will apply. The default is determined as follows:

For the SSLCipherSuite attribute of the SSL element in navajo.xml a default will be generated by the Virtual Host pattern.
For HttpsConnectorServlet nothing will be generated, and thus the default of this servlet applies. Read the documentation of the HttpsConnectorServlet for details.

SSL Options

The value configured here will be applied as SSLOptions.

It should only have value when assigned to a Virtual Host pattern.

Check the Apache Documentation for details.

If empty and when this pattern is assigned to a Virtual Host the following value is used:

+OptRenegotiate +StdEnvVars +ExportCertData

Generic Virtual Host Settings

#Application Protection #Generic #Add-ons

Customize the web.xml configuration using XML constructs as described in the nevisProxy Technical Documentation.

Use as add-on for the Virtual Host pattern. The following expressions are supported:

${name}: sanitized name of the pattern
${service.name}: the name of the virtual host
${service.id}: the unique ID of the virtual host
${service.path}: the base path of the virtual host (empty String)
${service.mapping}: the url-pattern for the virtual host /*

Filters and Mappings

Configure filters and their mappings using the XML syntax described in the nevisProxy Technical Documentation.

Example 1: Create (or patch) a filter with a fixed name

<filter>
   <filter-name>SomeName</filter-name>
   <filter-class>ch::nevis::isiweb4::filter::SomeClass</filter-class>
   <init-param>
      <param-name>...</param-name>
      <param-value>...</param-value>
   </init-param>
</filter>

Example 2: Create (or patch) a filter using an application-specific name

<filter>
   <filter-name>SomeName_${service.name}</filter-name>
   <filter-class>ch::nevis::isiweb4::filter::SomeClass</filter-class>
   ...
</filter>

Example 3: Map a filter to a sub-path of the assigned application(s). This example works for applications which have 1 frontend path only.

<filter-mapping>
   <filter-name>SomeFilter</filter-name>
   <url-pattern>${service.path}/custom/*</url-pattern>
</filter-mapping>

Example 4: Use multi-value expressions

Multi-value expressions replicate an entire line for each associated value.

Use the expressions *{service.path} and *{service.mapping} to generate filters which must contain the frontend paths of all assigned applications.

The following snippet is not complete but should illustrate the concept:

<filter>
    <filter-name>FormSigning</filter-name>
    <filter-class>ch::nevis::isiweb4::filter::validation::EncryptionFilter</filter-class>
    <init-param>
        <param-name>EntryURL</param-name>
        <param-value>
            *{service.path}/
        </param-value>
    </init-param>
    ...
</filter>

Filter Mappings

Choose between:

manual (default): only the filter-mapping elements which have been configured via Filters and Mappings will be added.
automatic: filters configured via Filters and Mappings will be mapped to /*.
both: like automatic but additional filter-mapping elements are allowed as well.

Filter Phase

When adding filter-mapping elements, a phase must be defined.

The phase defines where the filter-mapping is placed in the web.xml and ensures that filters are applied in the right order, relative to other phases.

The order within a certain phase is undefined as it must not matter.

The order for requests is START to END and END to START for responses.

This setting applies to all filter-mapping elements.

The filter-mapping elements may be provided via Filters and Servlets, or created automatically (see Filter Mappings for details).

Choose from the following filter phases:

START: applied as early as possible for requests and as late as possible for responses.
BEFORE_SANITATION: applied before filters which validate the request (e.g. Mod Security).
SANITATION: used for security. This is the first phase which allows accessing the session for applications protected by a realm.
AFTER_SANITATION: your request has passed security checks.
BEFORE_AUTHENTICATION: applied just before authentication.
AUTHENTICATION: used by the filter which connects to nevisAuth for applications which are protected by an Authentication Realm.
AFTER_AUTHENTICATION: the request has level 1 authentication. Used by Authorization Policy for Authentication Level stepup.
BEFORE_AUTHORIZATION: choose this phase to do preprocessing before authorization.
AUTHORIZATION: used by Authorization Policy for Required Roles check.
AFTER_AUTHORIZATION: used by patterns assigned as Application Access Token to applications.
END: applied as late as possible for requests and as early as possible for responses.

This setting is ignored when you patch a filter generated by another pattern (e.g. by adding, overwriting, or removing an init-param element) but do not create any filter-mapping element.

Servlets and Mappings

Configure servlet and/or servlet-mapping elements using the XML constructs described in the nevisProxy Technical Documentation.

You can also customize elements which have been generated by other patterns. Elements can be referenced as follows:

servlet: servlet-name
servlet-mapping: url-pattern

In Kubernetes side-by-side deployment a postfix is added to service names. Use the expression ${service.postfix} connecting to a service deployed against the same inventory.

Example 1: Add or overwrite an init-param for an existing servlet:

<servlet>
  <servlet-name>Hosting_Default</servlet-name>
  <init-param>
    <param-name>NoMatchFile</param-name>
    <param-value>/index.html</param-value>
  </init-param>
</servlet>

Example 2: Remove a servlet-mapping:

<servlet-mapping>
    <url-pattern>/app/*</url-pattern>
</servlet-mapping>

Here we left out the servlet-name to tell the pattern to remove the servlet-mapping for the given url-pattern.

Note that the mapping of the hosted resources is an exception and cannot be removed this way (see the property Hosted resources of the Virtual Host pattern for more information).

Removing a servlet element is not supported.

Template Parameters

Define Template Parameters.

Examples:

backend-host: backend.siven.ch

These parameters can be used in:

Servlets and Mappings
Filters and Mappings

The expression formats are:

${param.<name>}:

name found: parameter value is used.
name missing: expression is not replaced.

${param.<name>:<default value>}:

name found: parameter value is used.
name missing: default value will be used.

In <default value> the character } must be escaped as \}.

Remove Filter Mappings

Remove <filter-mapping> elements generated by other patterns.

This is an advanced configuration. Use only when you want to remove a <filter-mapping> but keep the <filter> element, e.g. to map it on a sub-location.

The syntax is a map of <filter-name>:<url-pattern>, according to values from the web.xml.

For instance, the following would remove the ErrorHandler_Default from /*:

ErrorHandler_Default:/*

Mime-Mappings

Set or replace mime-mapping elements.

Examples:

<mime-mapping>
    <extension>svg</extension>
    <mime-type>image/svg+xml</mime-type>
</mime-mapping>

The mime-mapping elements affect the entire Virtual Host and are used use to determine the Content-Type for responses.

nevisProxy always sets a Content-Type header for static resources served by the Virtual Host.

Further, nevisProxy can add a Content-Type header for resources served by applications. To enable this advanced feature assign Generic Application Settings to the application and set the parameter ProxyPolicy to mime-completion.

Geolocation Service

#Application Protection #Add-ons #Experimental

This pattern sets up a service that responds with the geolocation of the caller, based on the callers source IP.

The response is a JSON with the following format:

{
  "query":"<IP>"
  "status":"success|fail"
  "continentCode":"<ISO continent code>"
  "countryCode":"<ISO country code>"
  "licence":"https://www.maxmind.com/en/geolite2/eula"
}

The pattern requires that nevisProxy is able to correctly determine the source IP for the incoming request.

If a component in front of nevisProxy terminates TLS connections (e.g. a load balancer, ingress, Cloudflare), then you have to configure a Source IP Header in the Virtual Host pattern.

Virtual Host(s)

Assign a Virtual Host which shall serve as entry point.

Frontend Path

The path on which the service shall be accessible.

Geolocation Database

Upload a Maxmind database file.

For further information, see the documentation in the nevisProxy reference guide.

Authentication Realm

Optionally assign a realm to protect this application or service.

Additional Settings

Assign add-on patterns to customize the behavior of this service.

Example use cases:

Authorization Policy to enforce roles or an authentication level.
URL Handling to redirect or forward requests.
HTTP Header Customization to add, replace, or remove HTTP headers in requests or responses.

gRPC Service

#Application Protection #Applications

Set up access to a backend application providing a gRPC API.

Virtual Host(s)

Assign Virtual Host patterns which shall serve as entry point for this application. HTTP/2 has to be enabled on each Virtual Host.

Frontend Path(s)

The (base) path of the application.

Examples:

/app/ - defines a base path.

Any requests which have a path component starting with /app/ will be sent to this application.

/ - forward all requests to this application.

Use this only when there are no other applications or hosted resources.

exact:/app.html - matches requests to /app.html only (query parameters are allowed).

Use this for single-page applications which do not require any additional resources.

Note that if the frontend path is different from the path used within Backend Addresses then URL rewriting will be configured to correctly route requests and responses between clients and backends.

Authentication Realm

Optionally assign a realm to protect this application or service.

Application Access Token

Propagate a token to the backend application. The token informs the application about the authenticated user.

For instance, assign Nevis SecToken if the application uses Ninja or SAML Token for applications which are able to consume SAML Responses.

Additional Settings

Assign add-on patterns to customize the behavior of this service.

Example use cases:

Authorization Policy to enforce roles or an authentication level.
URL Handling to redirect or forward requests.
HTTP Header Customization to add, replace, or remove HTTP headers in requests or responses.

Backend Addresses

Enter the complete URL (scheme, host, port and path) of the gRPC service.

Note:

Only one backend is allowed.
Automatic path rewriting will be performed when the path differs from the Frontend Path.

Key Store

Optional setting to use a client certificate for connecting to HTTPS backends.

Trust Store

Optional setting for enabling trust to HTTPS backends.

For securing production environments:

set Backend Addresses starting with https://
assign a Trust Store pattern containing the certificates required for verifying the backend certificate
set Hostname Validation to enabled

Hostname Validation

Enable to verify that the hostname on the certificate presented by the backend matches the hostname configured in Backend Addresses

Host Header

Defines the Host header for requests forwarded to the application.

When backend is selected then nevisProxy uses the host part of the backend address that has been selected. This is the default behavior and similar to what a browser would do. Therefore, this configuration should work in most cases.

When client is selected then nevisProxy will keep the Host header as received from the client. The following init-param will be generated:

<init-param>
  <param-name>HostName</param-name>
  <param-value>ENV:HTTP_Host;</param-value>
</init-param>

The configuration is dynamic to support virtual hosts with multiple frontend addresses. Note that this may be less secure. Even though browsers do not allow this clients may sent an arbitrary value for the Host header. It is therefore recommended to test how your application behaves in this case.

Outbound Client Authentication

Controls whether the service access presents a client certificate on outbound TLS connections.

automatic follows the referenced target's server-side client-authentication setting. required ensures that client authentication is used, preserving an explicitly configured key store and generating an implicit identity only when no key store is configured. disabled prevents client authentication and is rejected when the referenced target requires it.

Allowed HTTP Methods

Define the HTTP methods allowed for this application.

Methods which are listed here must also be allowed on the Virtual Host.

The only valid HTTP method used in gRPC over HTTP/2 is POST.

Note: While gRPC itself only uses POST, higher-level frameworks like Cloud Endpoints support HTTP/JSON transcoding, which can map HTTP GET, POST, PUT, and DELETE methods to gRPC methods using annotations (e.g., option (google.api.http) = { get: "/v1/shelves/{shelf}" };).

Custom Parameters

Add custom init-param(s) for the Http2Servlet. For example: ConnectionPoolSize=200

Please check the nevisProxy technical documentation for supported init-params of the servlet class ch::nevis::nevisproxy::servlet::connector::http::Http2Servlet.

Hosting Service

#Application Protection #Applications

Use the pattern to host static pages and related resources.

For instance, you can use this pattern to host HTML or a single-page application (SPA).

Further, you can provide CSS, images, and Javascript for error pages uploaded by a HTTP Error Handling pattern.

The pattern generates configuration for the nevisProxy ch::nevis::nevisproxy::servlet::file::FileReaderServlet.

Virtual Host(s)

Assign a Virtual Host which shall serve as entry point.

Frontend Path

The path at which the resources shall be accessible at the frontend. You may use / to deploy root content.

Resources

Upload your resources here.

All files will be deployed in the same directory. Please use standard extensions (e.g. .css, .png, .html, .htm) only.

If you want to use subdirectories please upload a .zip file instead. The content of the .zip file will be unpacked.

Default File

Defines a default file which will be returned when there is no other matching file.

Authentication Realm

Optionally assign a realm to protect this application or service.

Rewrite Rules

Rewrite rules for serving files.

This can be useful if a file should be served under a different name, or to map extensions to file names.

Examples:

Source	Destination
`/static/picture`	`/static/picture.jpg`

Additional Settings

Assign add-on patterns to customize the behavior of this service.

Example use cases:

Authorization Policy to enforce roles or an authentication level.
URL Handling to redirect or forward requests.
HTTP Header Customization to add, replace, or remove HTTP headers in requests or responses.

HTTP Error Handling

#Application Protection #Add-ons

Use the pattern to handle HTTP error codes.

You can use the pattern as an add-on for Virtual Host or any backend application, for example, Web Application, REST Service, or SOAP Service.

Error Pages

Upload HTML error pages, JSON error pages and associated resources here.

Pages must be named like the error code they are used for (e.g. 500.html). You can use the same page for multiple status code (e.g. 401,403,500-599.html).

By default, the error pages are deployed to /errorpages/<name> but you can set a different location via the property Base Path (see Advanced Settings).

In your error pages we recommend using relative links to include resources. You may also include resources deployed on the virtual host via Hosted Resources.

The following placeholders are supported:

TRANSFER_ID for the unique ID of the request (e.g. c0a80e52-5d04-11ac0500-16906714eee-00000003)
TIMESTAMP to show a timestamp (e.g. Tue, 19 Feb 2019 15:48:02 GMT)

Blocked Status Codes

Hide certain HTTP status code(s) by returning 200 OK instead (by using the reset-status-code action).

By default, the status code is not changed as it can be useful for technical clients.

The response body will still be replaced.

You may also enter:

ranges of status codes (e.g. 500-599),
lists (e.g. 403,500)
combination thereof (e.g. 403,500-599).

Redirect Status Code Mapping

Redirect to a given location instead of rewriting the response body.

Locations can be entered as:

URLs (starting with http:// or https://)
paths (starting with /)

Internal and external locations are supported.

Examples:

404,500-599 -> /some/super/redirect/
403 -> https://www.google.com

Keep Header Status Codes

By default, HTTP headers are dropped when an error code is handled.

This avoids information leakage but can lead to session loss in some cases.

For instance, the nevisProxy session will be lost when all the following holds:

this pattern is configured to handle code 502.
the application is unreachable (502 is produced).
the nevisProxy session cookie is renegotiated (Set-Cookie header is set).
user refreshes the page after the error page is shown.

To overcome this limitation you may enter 502 here.

Note that we are investigating additional measures and may adapt this property in future releases.

Overwrite Status Codes

Overwrite certain HTTP status code(s) by returning with the defined status code instead.

If for an error code both Blocked Status Code and Overwrite Status Code is configured, the Blocked Status Code will take precedent.

Examples:

404,406-499 -> 401
405 -> 200

Mode

Enable or disable the error handling.

When set to disabled, all settings except Apply only to sub-paths are ignored. Use this setting in combination with Apply only to sub-paths to disable the error handling for some sub-paths only.

Usage examples (valid for Virtual Hosts and backend applications):

Disable the error handling:

use an Error Handler pattern with Mode set to disabled and link it to the target pattern via Additional Settings;

Disable the error handling for some sub-paths:

use an Error Handler pattern with Mode set to disabled and Apply only to sub-paths set to the paths where no error handling should occur, and link it to the target pattern via Additional Settings;

Define a customised error handling and disable it for some sub-paths:

use two Error Handler patterns, one with the custom settings, and one with Mode set to disabled and Apply only to sub-paths set to the paths where no error handling should occur. Link both of them to the target pattern via Additional Settings.

Apply only to sub-paths

Set to apply the error handling on some sub-paths only.

Sub-paths must be relative (e.g. not starting with /) and will be appended to the frontend path(s) of the virtual host (/) or applications this pattern is assigned to.

Sub-paths ending with / are treated as a prefix, otherwise an exact filter-mapping will be created.

The following table provides examples to illustrate the behavior:

Frontend Path	Sub-Path	Effective Filter Mapping
`/`	`secure/`	`/secure/*`
`/`	`accounts`	`/accounts`
`/`	`api/secure/`	`/api/secure/*`
`/`	`api/accounts`	`/api/accounts`
`/app/`	`secure/`	`/app/secure/*`
`/app/`	`accounts`	`/app/accounts`
`/app/`	`api/secure/`	`/app/api/secure/*`
`/app/`	`api/accounts`	`/app/api/accounts`

Content-Type Mode

The Content-Type Mode allows enabling or disabling the error handling depending on the Content-Type header of the backend response. Use this setting in combination with the Content-Types setting.

Choose one of:

None: The error handling settings are applied to all backend responses.
Enabled: The error handling settings are enabled only for the backend responses with a Content-Type header included in the Content-Types setting.

Backend responses with other Content-Types are propagated to the client.

Disabled: The error handling settings are disabled for the backend responses with a Content-Type header included in the Content-Types setting.

These responses are propagated to the client. The error handling settings are applied to backend responses with other Content-Type headers.

Content-Types

The Content-Types configures the Content-Type headers for which the Content-Type Mode setting is applied. Enter one value per line.

Use this setting in combination with the Content-Type Mode setting.

Base Path

By default, the error pages are deployed to /errorpages/<name> but you can set a different location here.

Keep Security Headers

Configure the name of special response headers which should be kept, regardless of the header action of the matching rule. Useful for keeping the security response headers for the error pages.

Default:

Strict-Transport-Security
X-Content-Type-Options
Referrer-Policy

HTTP Header Customization

#Application Protection #Add-ons

Use to add, overwrite, or remove HTTP headers in requests or responses.

You can use the pattern as add-on for Virtual Host or applications, for example, Web Application, REST Service, or SOAP Service.

The following expressions may be used:

${client.ip} - IP address of the caller
${request.id} - unique ID of this request
${request.header.<name>} - value of a request header (only for requests)
${env.<name>} - Apache ENV variables
${auth.<name>} - access to the AUTH scope (only for requests, requires an Authentication Realm and the Filter Phase is to be set to AFTER_AUTHENTICATION or END)

Add / Overwrite Headers

Adds/overwrites HTTP headers in requests.

The syntax is: <header name>:<value>

Examples:

X-Forwarded-For: ${client.ip}
User-ID: ${auth.user.auth.UserId}

Note: change the Filter Phase to replace headers early / late.

In order to use the ${exec: ...} syntax of nevisProxy for passwords, use an inventory secret to skip the validation of the value.

Basic Auth User

Enter the basic auth user or an expression of the format <source>:<parameter>.

For the <source> you may use:

AUTH: outargs returned by nevisAuth.
CONST: constant strings.
ENV: Apache environment variables.
PARAM: values from a request body as provided by a ParameterFilter.
HEADER: request headers.

Basic Auth Password

Enter the basic auth password or an expression of the format <source>:<parameter>.

For the <source> you may use:

AUTH: outargs returned by nevisAuth.
CONST: constant strings.
ENV: Apache environment variables.
PARAM: values from a request body as provided by a ParameterFilter.
HEADER: request headers.

Remove Headers

Removes HTTP headers from requests.

The syntax is: <header name>

Examples:

User-Agent

Note: change the Filter Phase to remove headers early / late.

Filter Phase

START - manipulate request headers early to hide them from validation and authentication.
AFTER_AUTHENTICATION - the original values are subject to validation and can be accessed in the authentication flow.

The header manipulation is applied afterwards to affect the application only.

END - manipulate request headers late, just before the request is forwarded to the application.

Add / Overwrite Headers

Adds/overwrites HTTP headers in responses.

The syntax is: <header name>:<value>

Force browser to use HTTPS only (1 day expiration):

Strict-Transport-Security: max-age=86400

Ensure pages are not cached:

Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0

Headers set by Apache (e.g. Server) cannot be overwritten.

Note: change the Filter Phase to set headers early / late.

Remove Headers

Removes HTTP headers from responses.

The syntax is: <header name>

Examples:

X-Content-Type-Options

Headers set by Apache cannot be removed:

Server

Note: change the Filter Phase to remove headers early / late.

Filter Phase

START - manipulate request headers late to also cover any headers set by nevisProxy.
AFTER_AUTHENTICATION - default behavior which should work in most cases.
END - manipulate response headers early hiding them from other nevisProxy filters which operate on responses.

Add / Overwrite Headers Condition

Set to do the header customization only if the given condition applies.

The condition is checked for Add / Overwrite Headers on requests and on responses.

You can use the expressions mentioned above.

Syntax:

${expression} == value

Examples:

${request.header.Content-Type} == application/x-www-form-urlencoded

Apply only to sub-paths

Set to apply the header customization on some sub-paths only.

Sub-paths must be relative (e.g. not starting with /) and will be appended to the frontend path(s) of the virtual host (/) or applications this pattern is assigned to.

Sub-paths ending with / are treated as a prefix, otherwise an exact filter-mapping will be created.

The following table illustrates the behavior:

Frontend Path	Sub-Path	Effective Filter Mapping
`/`	`secure/`	`/secure/*`
`/`	`accounts`	`/accounts`
`/`	`api/secure/`	`/api/secure/*`
`/`	`api/accounts`	`/api/accounts`
`/app/`	`secure/`	`/app/secure/*`
`/app/`	`accounts`	`/app/accounts`
`/app/`	`api/secure/`	`/app/api/secure/*`
`/app/`	`api/accounts`	`/app/api/accounts`

JWT Access Restriction

#Application Protection #Add-ons

Sets up a filter in nevisProxy to verify the JWT of incoming requests.

A request will be allowed to pass through if it contains a valid JWT, in every other case (e.g. failed to verify, expired or token not present), the request will be blocked. Blocked requests are responded to with HTTP error code 403

The pattern can be assigned to applications or an entire Virtual Host using Additional Settings. .

HTTP Header

By default, the JWT will be extracted from the Bearer type Authorization request header:

Authorization: Bearer <token>

Optionally, this behavior can be overwritten by this property by specifying a request header from where the token should be extracted, for example if the token is sent like:

CustomAuthHeader: <token>

Then configure CustomAuthHeader for this property.

Algorithm

The algorithm used to sign and verify the JWT.

Supported algorithms are:

RS256
RS384
RS512 (default)

Public Key

The public key corresponding to the private key which was used to sign the JWT.

Lua HTTP Processing

#Application Protection #Add-ons

Sets up a filter in nevisProxy which evaluates a Lua script.

The filter class is ch::nevis::isiweb4::filter::lua::LuaFilter.

Assign this pattern to your applications to perform complex request or response processing tasks.

Lua Script

Upload a Lua script which should be invoked for requests and / or responses. The script has to contain one or multiple of the following Lua functions:

function inputHeader(request, response) - called once per request
function input(request, response, chunk) - called once per request body chunk
function outputHeader(request, response) - called once per response
function output(request, response, chunk) - called once per response body chunk

The uploaded script will be deployed to the nevisProxy host in sub-directory WEB-INF using the name of this pattern for the file name to ensure that the file name is unique.

Here is an example Lua script which replaces sensitive information in response bodies:

local buf = {}
function output(request, response, chunk)
  if chunk ~= nil then
    table.insert(buf, chunk)
    return nil
  else
    return string.gsub(table.concat(buf), "some-sensitive-data", "*****");
  end
end

The following expressions can be used anywhere within the script:

${name} - sanitized name of this pattern
${host} - name of the Virtual Host directory
${instance} - name of the nevisProxy Instance directory

Lua Libraries

Upload addtional Lua libraries to be used within the Lua Script.

Uploaded files will be deployed to the following directory:

/var/opt/nevisproxy/${instance}/${host}/WEB-INF/lib/${name}/"

The Lua script must patch package.path so that the Lua libraries can be used.

For instance, add the following line at the beginning of the script:

package.path = package.path .. ";/var/opt/nevisproxy/${instance}/${host}/WEB-INF/lib/${name}/?.lua"

Filter Phase

Defines the position of the filter-mapping for this Lua filter. Which position to choose depends on your use case.

For requests filters will be invoked from START to END. For responses filters will be invoked from END to START.

Choose from the following filter phases:

START: applied as early as possible for requests and as late as possible for responses.
BEFORE_SANITATION: applied before filters which validate the request (e.g. Mod Security).
SANITATION: used for security. This is the first phase which allows accessing the session for applications protected by a realm.
AFTER_SANITATION: your request has passed security checks.
BEFORE_AUTHENTICATION: applied just before authentication.
AUTHENTICATION: used by the filter which connects to nevisAuth for applications which are protected by an Authentication Realm.
AFTER_AUTHENTICATION: the request has level 1 authentication. Used by Authorization Policy for Authentication Level stepup.
BEFORE_AUTHORIZATION: choose this phase to do preprocessing before authorization.
AUTHORIZATION: used by Authorization Policy for Required Roles check.
AFTER_AUTHORIZATION: used by patterns assigned as Application Access Token to applications.
END: applied as late as possible for requests and as early as possible for responses.

Script Parameters

Parameters defined here can be used inside the Lua script.

The name of each parameter must start with param_. This limitation may be lifted in a future release.

The value will be trimmed.

Set this property if you need a different value depending on the inventory.

click var to use a nevisAdmin 4 variable for the entire setting:
- Enter a good name for the variable as the default may be quite verbose.
- Enter some sample values to document the variable in the project.
add the nevisAdmin 4 variable to your inventories:
- See below for an example which illustrates the syntax.

Example inventory variable:

vars:
  example-variable:
    param_example_string: "on"
    param_example_numeric: 60

It is sometimes required to quote values. In the example above, the value on would be converted to a boolean value if it weren't for the double quotes ". When unsure, always put double quotes around the value.

Apply only to sub-paths

Set to apply this pattern on some sub-paths only.

Sub-paths must be relative (e.g. not starting with /) and will be appended to the frontend path(s) of the virtual host (/) or applications this pattern is assigned to.

Sub-paths ending with / are treated as a prefix, otherwise an exact filter-mapping will be created.

The following table provides examples to illustrate the behavior:

Frontend Path	Sub-Path	Effective Filter Mapping
`/`	`secure/`	`/secure/*`
`/`	`accounts`	`/accounts`
`/`	`api/secure/`	`/api/secure/*`
`/`	`api/accounts`	`/api/accounts`
`/app/`	`secure/`	`/app/secure/*`
`/app/`	`accounts`	`/app/accounts`
`/app/`	`api/secure/`	`/app/api/secure/*`
`/app/`	`api/accounts`	`/app/api/accounts`

Apply Only Conditionally

Configure one or more conditions under which the configured rules should be triggered. Multiple conditions are combined with logical AND.

In the first column enter the key, for example ENV:REQUEST_URI. In the second column enter the regex which has to match, for example: .*\.js$.

Maintenance Page

#Application Protection #Add-ons

Shows a static maintenance page if the current date and time is within a certain interval.

Technical note: nevisProxy uses system calls to determine the current time in UTC. To check if UTC time is correct, run date -u on the nevisProxy host.

You can assign the pattern using Additional Settings to applications, or an entire Virtual Host.

Show Maintenance Page

Allows to easily enable / disable the maintenance with being forced to set a time window.

Start

Enter the start date and time of the maintenance window.

format: yyyy-mm-dd HH:mm (24 hours)
timezone: UTC (not your local time)
example: 2020-05-20 15:00

End

Enter the end date and time of the maintenance window.

format: yyyy-mm-dd HH:mm (24 hours)
timezone: UTC (not your local time)
example: 2020-05-20 15:00

Maintenance Page

The page must contain two meta-tags which define the maintenance interval and will be patched during generation.

Example:

<head>
  <meta name="maintenance-start" content="${maintenance-start-value}">
  <meta name="maintenance-end" content="${maintenance-end-value}">
</head>

If the date and time on the target host are within this interval, the maintenance page will be shown. See also the introduction help text above.

Status Code

The status code of the response with the maintenance page.

By default, the response is sent with status code 503 for Service Unavailable.

Base Path

Enter the base path under which the maintenance page will be hosted.

You usually do not have to change this configuration, unless the path clashes with any other hosted resources.

By default, /maintenance/ is used.

Update Interval

Enter the time interval between checks of the maintenance page.

In normal mode, the system checks the maintenance page for updates when a request comes in, if the configured interval has passed since the last check.
In maintenance mode, the system ignores the UpdateInterval and fetches the maintenance page on each request.

nevisProxy Observability Settings

#Application Protection #Add-ons

Sets up observability with OpenTelemetry for nevisProxy.

The OpenTelemetry settings are applied to each Virtual Host of the instance.

Transport Protocol

Choose one of:

gRPC: The nevisProxy OpenTelemetry service supports gRPC
http: The nevisProxy OpenTelemetry service does not support gRPC

Trace Mode

Choose one of:

enabled: enable the trace feature of OpenTelemetry
disabled: disable the trace feature of OpenTelemetry

Trace Exporter Address

Enter the target URL ([http[s]://]host:port) of the backend services to which the exporter is going to send spans. The /v1/traces path is automatically attached to it. This parameter is required if a Deployment Environment is set.

Trace Exporter Trust Store

Optional setting for enabling trust to the Opentelemetry service.

For securing production environments:

set Trace Exporter Address starting with https://
assign a Trust Store pattern containing the certificates required for verifying the backend certificate

Trace Exporter Key Store

Optional setting to use a client certificate for connecting to the Opentelemetry service.

Metrics Mode

Choose one of:

enabled: enable the metrics feature of OpenTelemetry
disabled: disable the metrics feature of OpenTelemetry

Metrics Exporter Address

Enter the target URL ([http[s]://]host:port) of the backend services to which the exporter is going to send metrics. The /v1/metrics path is automatically attached to it.

Metrics Exporter Trust Store

Optional setting for enabling trust to the Opentelemetry service.

For securing production environments:

set Metrics Exporter Address starting with https://
assign a Trust Store pattern containing the certificates required for verifying the backend certificate

Metrics Exporter Key Store

Optional setting to use a client certificate for connecting to the Opentelemetry service.

Resource Service Name

Configure the service.name key-value pair resource attribute.

Deployment Environment

Allows the configuration of the deployment.environment.name key-value pair resource attribute. The configured value will be the values of the deployment.environment.name attribute sent to the OpenTelemetry service.

Logs Mode

Choose one of:

enabled: enable the logs feature of OpenTelemetry
disabled: disable the logs feature of OpenTelemetry

Logs Exporter Address

Enter the target URL ([http[s]://]host:port) of the backend services to which the exporter is going to send the logs. The /v1/logs path is automatically attached to it.

Logs Exporter Trust Store

Optional setting for enabling trust to the OpenTelemetry service.

For securing production environments:

set Logs Exporter Address starting with https://
assign a Trust Store pattern containing the certificates required for verifying the backend certificate

Logs Exporter Key Store

Optional setting to use a client certificate for connecting to the OpenTelemetry service.

Sampler

Configure the available head sampling methods. Possible values are:

AlwaysOn: Samples every trace. With high traffic in a production application, it may cause significant overhead.
AlwaysOff: Samples no traces. NevisProxy still generates the spanID for internal trace ID.
TraceIdRatio:<ratio>: Samples a given fraction of traces based on the configured ratio.
ParentBased:<delegate_sampler>: Makes the decision based on the parent of the span.
- If the span has a parent, the sampler flag of the parent span will decide.
- If there is no parent span, the delegate sampler is used; that can be any of the samplers above.

Trace Context Extraction

Choose one of:

enabled: if present, extract the trace context from the HTTP request header and set it as parent for the current span
disabled: ignore the trace context from the HTTP request header

Trace Context Injection

Choose one of:

enabled: inject the current context (span ID, trace ID, etc.) as a HTTP header to the request
disabled: do not inject the current context in the request

Capture Request Headers

HTTP client instrumentation will capture HTTP request header values for all configured header names.

Default in nevisProxy:

Content-Type, Content-Length, User-Agent, Referer, Host, X-Forwarded-For

Capture Response Headers

HTTP client instrumentation will capture HTTP response header values for all configured header names.

Default in nevisProxy:

Content-Type, Content-Length, Content-Encoding, Location, Server, Connection, Keep-Alive, X-Forwarded-For

Metrics Timeout

Configures a timeout for the metrics observable callback.

Metrics Interval

Interval of the metrics reader to initiate metrics collection.

Request Validation Settings (ModSecurity)

#Application Protection #Add-ons

Use the pattern to customize ModSecurity rules. Assign the same pattern to multiple applications to enforce a common configuration.

Do not use rule IDs in the range 500001-500999 as they are reserved for Nevis internal purposes.

Deploying changes to an existing pattern triggers a restart of nevisProxy if the RestartPolicy is set to eager.

Restarting the instance better suits large and highly customised ModSecurity setups.

If you prefer to let nevisProxy reload the ModSecurity configuration on-the-fly, set the RestartPolicy to lazy in the corresponding nevisProxy Instance patterns.

Validation Scope

Sets the scope of request validation:

all: validation will be applied to all requests. This includes authentication.
backend: validation will be applied to requests which are sent to the backend application. The authentication is excluded.
authentication: validation will be applied to requests which are sent to nevisAuth.

Log Only Mode

Allows to use the request validation settings in log only mode.

Paranoia Level

Sets the paranoia level of the ModSecurity OWASP Core Rule Set (CRS). Please see https://coreruleset.org/faq/ for more details.

Paranoia level 1 (PL1) is recommended for beginners and setups with standard security requirements. If you encounter false positives at PL1 OWASP recommends to raise an issue at their Github site.
Paranoia level 2 (PL2) includes SQL, XSS and code injection rules. PL2 is recommended for setups with elevated security requirements and advanced users.
Paranoia level 3 (PL3) enables additional rules and keyword lists to cover less common attacks. Consider PL3 if you are experienced at handling false-positives and for sites with high security requirements.
Paranoia level 4 (PL4) also restricts special characters. PL4 may produce a lot of false positives so please do extensive testing before going into production.

Rule Modifications

Use to add, modify, or remove ModSecurity rules.

Use the Rule recommender to white-list requests. Click the link to open the dialog, then paste log snippets from the nevisProxy navajo.log for requests which have been blocked by ModSecurity.

The log statement must contain the trace group IW4ModsecF and at least the id of the ModSecurity rule which has blocked the request. Example:

2020-07-21 13:00... IW4ModsecF ... Matched "Operator `Rx' with parameter ... against variable `REQUEST_BODY' ... [id "930100"] ... [uri "/nevisidm/admin/"]

The recommender will propose ModSecurity modifications to prevent these requests from being blocked in the future. The modifications will be as specific as possible, including the path, as well as parameters from the request. Please review the recommended modifications and adapt as required.

You may also enter your own rules or modifications directly, skipping the recommender dialog. Check the ModSecurity documentation for further information on how to modify rules.

Both exception modifications or whitelist modifications are allowed in this box. The pattern ensures that the statements are included into the correct place in the generated ModSecurity configuration.

New ModSecurity rules require a rule ID which has to be unique within this pattern and must not used in the rule set. According to ModSecurity documentation the range 1-99999 is reserved for local (internal) use. The rule recommender will use the range 10001-10999.

Whitelist Modifications

Configure whitelist modifications.

As explained in the ModSecurity documentation whitelist modifications are applied before including the core rules.

Note that new rule may require a rule ID which has to be unique for this pattern. Use the range 1-99,999 as it is reserved for local (internal) use.

Remove rule with ID 900200 for the path /app/some.html:

SecRule REQUEST_URI "@streq /app/some.html" "pass,nolog,id:1000,ctl:ruleRemoveById=200002"

Exception Modifications

Configure exception modifications.

As explained in the ModSecurity documentation exception modifications are applied after including the core rules.

Note that new rule may require a rule ID which has to be unique for this pattern. Use the range 1-99,999 as it is reserved for local (internal) use.

Remove rule with ID 900200:

SecRuleRemoveById 900200

Whitelist body parameter upload for all rules:

SecRuleUpdateTargetByTag ".*" "!ARGS:upload"

Whitelist body parameter upload for rule ID 123:

SecRuleUpdateTargetById 123 !ARGS:upload

Add a new rule which allows the HTTP methods used for WebDAV:

SecAction \
 "id:1,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:'tx.allowed_methods=GET HEAD POST OPTIONS PUT PATCH DELETE CHECKOUT COPY DELETE LOCK MERGE MKACTIVITY MKCOL MOVE PROPFIND PROPPATCH PUT UNLOCK'"

Template Parameters

Define parameters which may be used within rules.

Enter a map of key-value pairs.

For instance, a parameter my_param could be defined as follows:

my_param: 900200

These parameters can be used in:

Additional Rules
Whitelist Modifications
Exception Modifications

The expression formats are:

${param.<name>}:

name found: parameter value is used.
name missing: expression is not replaced.

${param.<name>:<default value>}:

name found: parameter value is used.
name missing: default value will be used.

In <default value> the character } must be escaped as \}.

In case a variable my-variable is used this is the format you need to use in the inventory:

my-variable: |
  my_param: 900200

Rule Bundle

Add a Rule Bundle pattern for global or group ModSecurity rule configuration.

Response Rewrite Settings

#Application Protection #Add-ons

Use the pattern to replace the hostname of the backend or transform response bodies using regular expressions.

Backend Host Rewriting

off disables automatic response rewriting
header enables auto rewrite of response headers (includes cookies)
complete enables auto rewrite for response headers and body

Response Body Rewriting

Configure response body rewrite rules.

In the first column enter a regular expression. In the second column enter the replacement.

Rules will be applied to each line of the response body.

Response body rewriting can be a complex task and should only be done if there is no other way. Use the browser's network tracing to have a look at the responses to find out what needs to be rewritten.

Examples:

Regex	Replacement	Description
`http://my-backend.intra.siven.ch`	`https://www.siven.ch`	replace an internal host name with the external one
`https?://[^/]+(/.*)`	`$1`	make links relative
`<base href="/">`	`<base href="/app/">`	apps which have a context root of `/` may require a rewrite of the `base` element

For further information see documentation of RewriteFilter in nevisProxy Technical Documentation.

Response Body Content Types

Enter regular expressions to match the Content-Type of responses. If the expression matches, the response body is rewritten.

Response Body Mapping Rules

Configure one or more conditions under which the rewrite rules should be triggered. Multiple conditions are combined with logical AND.

In the first column enter the key, for example ENV:REQUEST_URI. In the second column enter the regex which has to match, for example: .*\.js$.

REST Service

#Application Protection #Applications

Set up access to a backend application providing a REST API.

Virtual Host(s)

Assign Virtual Host patterns which shall serve as entry point for this application.

Frontend Path(s)

The (base) path of the application.

Examples:

/app/ - defines a base path.

Any requests which have a path component starting with /app/ will be sent to this application.

/ - forward all requests to this application.

Use this only when there are no other applications or hosted resources.

exact:/app.html - matches requests to /app.html only (query parameters are allowed).

Use this for single-page applications which do not require any additional resources.

Note that if the frontend path is different from the path used within Backend Addresses then URL rewriting will be configured to correctly route requests and responses between clients and backends.

Authentication Realm

Optionally assign a realm to protect this application or service.

Application Access Token

Propagate a token to the backend application. The token informs the application about the authenticated user.

For instance, assign Nevis SecToken if the application uses Ninja or SAML Token for applications which are able to consume SAML Responses.

Additional Settings

Assign add-on patterns to customize the behavior of this service.

Example use cases:

Authorization Policy to enforce roles or an authentication level.
URL Handling to redirect or forward requests.
HTTP Header Customization to add, replace, or remove HTTP headers in requests or responses.

Backend Addresses

Enter the complete URLs (scheme, host, port and path) of the backend services.

Note:

all URLs must use the same scheme and path.
automatic path rewriting will be performed when the path differs from the Frontend Path.

In case you are setting multiple addresses, use Load Balancing to select a request dispatching strategy.

Load Balancing

Select a request dispatching strategy when several Backend Addresses are configured.

disabled - all requests will be sent to the first address. If this address is not available the next address is chosen;
round-robin - one of the addresses will be picked up for each request using a round-robin rotation;
session-sticky - one of the addresses will be picked up for each new session using a round-robin rotation, then subsequent requests for the session will be sent to the same address.

Failover strategy:

When the selected backend cannot be accessed, nevisProxy will attempt to use another one.
Once the said backend can be accessed again, it can be picked up for new requests if the load balancing is round-robin, or for new sessions if the load balancing is disabled or session-sticky.

The requests linked to an existing session will still go to the current backend until the end of the session if the load balancing is disabled or session-sticky.

Key Store

Optional setting to use a client certificate for connecting to HTTPS backends.

Send Certificate Chain

Choose which certificates are sent to the backend during mutual authentication:

disabled: Send the client certificate from the Key Store;
enabled: Send the certificate chain from a PEM Key Store or a nevisKeybox Store.

The certificate chain file must contain the client certificate and the intermediate CA certificates.

Trust Store

Optional setting for enabling trust to HTTPS backends.

For securing production environments:

set Backend Addresses starting with https://
assign a Trust Store pattern containing the certificates required for verifying the backend certificate
set Hostname Validation to enabled

Hostname Validation

Enable to verify that the hostname on the certificate presented by the backend matches the hostname configured in Backend Addresses

Host Header

Defines the Host header for requests forwarded to the application.

When client is selected then nevisProxy will keep the Host header as received from the client. The following init-param will be generated:

<init-param>
  <param-name>HostName</param-name>
  <param-value>ENV:HTTP_Host;</param-value>
</init-param>

Response Rewriting

Use this feature to replace backend hostnames in responses or set to custom to configure complex rewriting use cases.

off disables automatic response rewriting
header enables auto rewrite for response headers (including Set-Cookie header)
complete enables auto rewrite for the entire response (including body)
custom configure Response Rewriting Settings via Additional Settings

Outbound Client Authentication

Controls whether the service access presents a client certificate on outbound TLS connections.

CSRF Protection

Cross-Site Request Forgery (CSRF) is an attack that forces an authenticated user to send unwanted requests.

off (default) - no CSRF protection. Recommended for APIs which may be called from other sites.
header-based - GET and HEAD requests are allowed.

For other requests Referer and Origin headers must match the Host header.

JSON Validation

Choose between:

enabled - all requests which have a request body must be valid JSON.
log only - similar to enabled but violations are not blocked, only logged.
content-type - validation is performed only when the Content-Type header matches application/json.
disabled

OpenAPI Validation File

You can configure an OpenAPI validation file in JSON format. All incoming requests to this service will be validated against that file.

Allowed HTTP Methods

Define the HTTP methods allowed for this application.

Methods which are listed here must also be allowed on the Virtual Host.

You may also use the following method groups:

ALL-HTTP includes common HTTP methods.

These are: GET, POST, HEAD, DELETE, TRACE, CONNECT, OPTIONS, PUT, PATCH
ALL-WEBDAV includes all methods required for WebDAV.

These are: MERGE, UNCHECKOUT, MKACTIVITY, PROPPATCH, LOCK, CHECKOUT, SEARCH, COPY, MKCOL, MKWORKSPACE, PROPFIND, UPDATE, REBIND, BASELINE-CONTROL, UNBIND, CHECKIN, VERSION-CONTROL, UNLOCK, LABEL, MOVE, ACL, BIND, REPORT

To remove methods from ALL-HTTP and ALL-WEBDAV simply add the method with a - sign in front of it.

Session Termination

Use this feature to terminate sessions on the backend application.

nevisProxy will send a GET request to this path when the nevisProxy session is terminated (due to logout or session timeout).

Custom Parameters

Add custom init-param(s) for the Http(s)ConnectorServlet. For example: ConnectionRetries=10

Please check the nevisProxy technical documentation for supported init-params of the servlet classes ch::nevis::isiweb4::servlet::connector::http::HttpConnectorServlet and ch::nevis::isiweb4::servlet::connector::http::HttpsConnectorServlet.

Rule Bundle (ModSecurity)

#Application Protection #Add-ons

Use the pattern to further customize ModSecurity rules.

Assign the same pattern to multiple Request Validation Settings patterns to easily configure and maintain global or group ModSecurity rule configurations.

Do not use rule IDs in the range 500001-500999 as they are reserved for Nevis internal purposes.

Whitelist Modifications

Configure whitelist modifications.

As explained in the ModSecurity documentation whitelist modifications are applied before including the core rules.

If both the Request Validation Settings and the Rule Bundle pattern have whitelist modifications configured, first the Rule Bundle, then the Request Validation Settings whitelists will be applied.

Note that new rule may require a rule ID which has to be unique for this pattern. Use the range 1-99,999 as it is reserved for local (internal) use.

Remove rule with ID 900200 for the path /app/some.html:

SecRule REQUEST_URI "@streq /app/some.html" "pass,nolog,id:1000,ctl:ruleRemoveById=200002"

Exception Modifications

Configure exception modifications.

As explained in the ModSecurity documentation exception modifications are applied after including the core rules.

If both the Request Validation Settings and the Rule Bundle pattern have exception modifications configured, first the Request Validation Settings, then the Rule Bundle modifications will be applied.

Note that new rule may require a rule ID which has to be unique for this pattern. Use the range 1-99,999 as it is reserved for local (internal) use.

Remove rule with ID 900200:

SecRuleRemoveById 900200

Whitelist body parameter upload for all rules:

SecRuleUpdateTargetByTag ".*" "!ARGS:upload"

Whitelist body parameter upload for rule ID 123:

SecRuleUpdateTargetById 123 !ARGS:upload

Add a new rule which allows the HTTP methods used for WebDAV:

SecAction \
 "id:1,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:'tx.allowed_methods=GET HEAD POST OPTIONS PUT PATCH DELETE CHECKOUT COPY DELETE LOCK MERGE MKACTIVITY MKCOL MOVE PROPFIND PROPPATCH PUT UNLOCK'"

Security Response Headers

#Application Protection #Add-ons

Configure security headers to be set by nevisProxy on responses. Assign the pattern to an entire Virtual Host or individual applications.

Response Headers

Use this property to add security headers to responses. The syntax is: <header name>:<value>

Example:

Strict-Transport-Security: max-age=63072000
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

SOAP Service

#Application Protection #Applications

The pattern sets up access to a backend application which provides a SOAP service.

Virtual Host(s)

Assign Virtual Host patterns which shall serve as entry point for this application.

Frontend Path

The (base) path of the application.

Examples:

/app/ - defines a base path.

Any requests which have a path component starting with /app/ will be sent to this application.

/ - forward all requests to this application.

Use this only when there are no other applications or hosted resources.

exact:/app.html - matches requests to /app.html only (query parameters are allowed).

Use this for single-page applications which do not require any additional resources.

Note that if the frontend path is different from the path used within Backend Addresses then URL rewriting will be configured to correctly route requests and responses between clients and backends.

Authentication Realm

Optionally assign a realm to protect this application or service.

Application Access Token

Propagate a token to the backend application. The token informs the application about the authenticated user.

For instance, assign Nevis SecToken if the application uses Ninja or SAML Token for applications which are able to consume SAML Responses.

Additional Settings

Assign add-on patterns to customize the behavior of this service.

Example use cases:

Authorization Policy to enforce roles or an authentication level.
URL Handling to redirect or forward requests.
HTTP Header Customization to add, replace, or remove HTTP headers in requests or responses.

Backend Addresses

Enter the complete URLs (scheme, host, port and path) of the backend services.

Note:

all URLs must use the same scheme and path.
automatic path rewriting will be performed when the path differs from the Frontend Path.

In case you are setting multiple addresses, use Load Balancing to select a request dispatching strategy.

Load Balancing

Select a request dispatching strategy when several Backend Addresses are configured.

disabled - all requests will be sent to the first address. If this address is not available the next address is chosen;
round-robin - one of the addresses will be picked up for each request using a round-robin rotation;
session-sticky - one of the addresses will be picked up for each new session using a round-robin rotation, then subsequent requests for the session will be sent to the same address.

Failover strategy:

When the selected backend cannot be accessed, nevisProxy will attempt to use another one.
Once the said backend can be accessed again, it can be picked up for new requests if the load balancing is round-robin, or for new sessions if the load balancing is disabled or session-sticky.

The requests linked to an existing session will still go to the current backend until the end of the session if the load balancing is disabled or session-sticky.

Key Store

Optional setting to use a client certificate for connecting to HTTPS backends.

Send Certificate Chain

Choose which certificates are sent to the backend during mutual authentication:

disabled: Send the client certificate from the Key Store;
enabled: Send the certificate chain from a PEM Key Store or a nevisKeybox Store.

The certificate chain file must contain the client certificate and the intermediate CA certificates.

Trust Store

Optional setting for enabling trust to HTTPS backends.

For securing production environments:

set Backend Addresses starting with https://
assign a Trust Store pattern containing the certificates required for verifying the backend certificate
set Hostname Validation to enabled

Hostname Validation

Enable to verify that the hostname on the certificate presented by the backend matches the hostname configured in Backend Addresses

Host Header

Defines the Host header for requests forwarded to the application.

When client is selected then nevisProxy will keep the Host header as received from the client. The following init-param will be generated:

<init-param>
  <param-name>HostName</param-name>
  <param-value>ENV:HTTP_Host;</param-value>
</init-param>

Response Rewriting

Use this feature to replace backend hostnames in responses or set to custom to configure complex rewriting use cases.

off disables automatic response rewriting
header enables auto rewrite for response headers (including Set-Cookie header)
complete enables auto rewrite for the entire response (including body)
custom configure Response Rewriting Settings via Additional Settings

Outbound Client Authentication

Controls whether the service access presents a client certificate on outbound TLS connections.

SOAP Schema Validation

Optional property to upload a schema.

This feature is experimental and may change in future releases.

You must upload all required XSD schema files. Each XSD schema file must declare 1 target namespace which will be extracted from the first targetNamespace attribute found in the file.

Upload of a WSDL file is optional. If provided, the WSDL must contain a types declaration containing an XSD schema. However, this schema definition can be empty. Here is a minimal example:

   <types>
      <xsd:schema targetNamespace="urn:com.example:echo"
                  elementFormDefault="qualified">
      </xsd:schema>
   </types>

The actual schemas must still be uploaded as separate files.

SOAP Schema Validation Mode

Choose between:

strict - all requests must be valid SOAP, requests without a body are blocked.
enabled - all requests which have a request body must be valid SOAP, requests without a body are allowed.
log only - similar to strict but violations are not blocked, only logged.
content-type - validation is performed only when the Content-Type header matches application/soap+xml.
disabled

Allowed HTTP Methods

Define the HTTP methods allowed for this application.

Methods which are listed here must also be allowed on the Virtual Host.

You may also use the following method groups:

ALL-HTTP includes common HTTP methods.

These are: GET, POST, HEAD, DELETE, TRACE, CONNECT, OPTIONS, PUT, PATCH
ALL-WEBDAV includes all methods required for WebDAV.

These are: MERGE, UNCHECKOUT, MKACTIVITY, PROPPATCH, LOCK, CHECKOUT, SEARCH, COPY, MKCOL, MKWORKSPACE, PROPFIND, UPDATE, REBIND, BASELINE-CONTROL, UNBIND, CHECKIN, VERSION-CONTROL, UNLOCK, LABEL, MOVE, ACL, BIND, REPORT

To remove methods from ALL-HTTP and ALL-WEBDAV simply add the method with a - sign in front of it.

Session Termination

Use this feature to terminate sessions on the backend application.

nevisProxy will send a GET request to this path when the nevisProxy session is terminated (due to logout or session timeout).

Custom Parameters

Add custom init-param(s) for the Http(s)ConnectorServlet. For example: ConnectionRetries=10

Static Content Cache

#Application Protection #Add-ons #Experimental

Use this pattern to configure a nevisProxy filter to cache responses returned by backend applications.

This pattern should only be configured for:

locations that emit static insensitive content,
early hint resources,
or backend applications that return Cache-Control headers to prevent storing sensitive responses.

Cached responses are stored in the directory:

/var/opt/nevisproxy/<instance>/run/cache/Cache_<pattern name>/

Stored response bodies can use up to Max Entries Max Entry Size of disk space. Stored response headers generally use less disk space, up to Max Entries ResponseLineSize of the HttpConnectorServlet (default: 4kB) * max number of response headers.

Max Entries

The maximum number of documents to be cached.

Max Entry Size

The maximum size of a document to be cached. Larger documents are never cached.

Max Lifetime

The maximum duration to cache a document.

Max-Age Mode

Choose one of:

override : The cache entry lifetime is set to Max Lifetime.
backend : The cache entry lifetime is copied from the Cache-Control: max-age directive sent by the backend. The Max Lifetime is used as a fallback.

Request Header Mode

Request headers can force an intermediate server to override its cache and answer with the response from the original server.

Choose one of:

comply : Follow the Cache-Control: no-cache directives sent by the client.
ignore : Answer with the stored response even if the client sent a Cache-Control: no-cache directive.

Response Header Mode

Response headers can indicate whether clients and intermediate servers should cache the response.

Choose one of:

comply : Follow the Cache-Control directives sent by the backend.
ignore : Store the response even if the backend sent a Cache-Control directive to prevent caching.

Be aware that ignoring Cache-Control directives can lead to sharing sensitive data between clients.

Some clients or content providers try to switch off caching even for mostly static content like images or style sheets. You can limit the load on your content providers as follows:

Add a Static Content Cache pattern and link it to your application via Additional Settings;
Configure Apply only to sub-paths to store responses on paths that only emit static content, for instance images;
Set Response Header Mode to ignore;
Configure the Max Lifetime of stored responses.

Apply only to sub-paths

Set to apply the cache handling on some sub-paths only.

Sub-paths must be relative (e.g. not starting with /) and will be appended to the frontend path(s) of the virtual host (/) or applications this pattern is assigned to.

Sub-paths ending with / are treated as a prefix, otherwise an exact filter-mapping will be created.

The following table provides examples to illustrate the behavior:

Frontend Path	Sub-Path	Effective Filter Mapping
`/`	`secure/`	`/secure/*`
`/`	`accounts`	`/accounts`
`/`	`api/secure/`	`/api/secure/*`
`/`	`api/accounts`	`/api/accounts`
`/app/`	`secure/`	`/app/secure/*`
`/app/`	`accounts`	`/app/accounts`
`/app/`	`api/secure/`	`/app/api/secure/*`
`/app/`	`api/accounts`	`/app/api/accounts`

TCP Settings

#Application Protection #Add-ons

Use the pattern to customize TCP connections to backend applications. Assign the same pattern to multiple applications to enforce a common standard.

You can also assign the pattern to a Virtual Host using Additional Settings. In this case, only Request Timeout applies - it sets the nevisProxy instance-wide Server Timeout in navajo.xml (the amount of time nevisProxy itself will wait before failing a request). All other settings (Connect Timeout, DNS Caching, Keep-Alive) only take effect when this pattern is assigned to a backend application.

`DNS Caching`	`Keep-Alive`	Description
`disabled`	`disabled`	Always works but has the biggest impact on latency.
`disabled`	`enabled`	DNS may resolve a new IP but Keep-Alive is enabled so some requests may still be routed to the previous IP. This may be acceptable if the previous IP is still reachable and could even be required in case sessions are bound to the TCP connection.
`enabled`	`disabled`	The resolved IPs are stable but for each request a new TCP connection is established.
`enabled`	`enabled`	The resolved IPs are stable and connections are reused.

Connect Timeout

Timeout for establishing the TCP connection.

Only applies when this pattern is assigned to a Service (backend application), not when assigned to a Virtual Host.

Request Timeout

Timeout waiting for the response.

When this pattern is assigned to a Service (backend application): this setting controls the connection from nevisProxy to that backend application.

When this pattern is assigned to a Virtual Host instead: this setting controls a different thing - the instance-wide Server Timeout attribute in navajo.xml (default 30 seconds), which bounds how long nevisProxy itself will wait before failing a request. If multiple Virtual Hosts on the same nevisProxy instance configure different values here, this results in a generation conflict, since Server Timeout is a single instance-wide setting.

Not to be confused with Request Timeout on the Gateway API Settings pattern, which controls the connection to nevisProxy (Envoy Gateway waiting for nevisProxy's response) in Kubernetes deployments.

All these timeouts can apply to the same end-to-end request, just for different hops. The request is terminated after whichever value is lower. If you raise the Gateway API Settings timeout above 30 seconds, also raise this setting on a Virtual Host accordingly. If you leave it unset, nevisProxy keeps its own default of 30 seconds, and the request will still be cut off inside nevisProxy before the higher Gateway API Settings timeout is ever reached.

If the same instance of this pattern is assigned to both a Service and its Virtual Host, this setting applies in both places at once: it sets the backend RequestTimeout in web.xml and the instance-wide Server Timeout in navajo.xml to the same value. This is valid, but keep in mind that a single value then governs two different hops of the chain; use two separate pattern instances (one per assignment) if you need different values for each.

DNS Caching

Cache DNS lookup results.

default: does not generate any configuration so the default nevisProxy behavior will apply.
disabled: the configured backend host names are resolved for each request. Use when IP addresses may change.
enabled: host names are resolved only once. Use when the IP addresses are stable.

Only applies when this pattern is assigned to a Service (backend application), not when assigned to a Virtual Host.

DNS Caching Timeout

If DNS Caching is set to true, DNS Caching Timeout specifies how long the DNS info should be cached (in seconds) before getting again the IP address.

Only applies when this pattern is assigned to a Service (backend application), not when assigned to a Virtual Host.

Keep-Alive

Pool TCP connections to backends for later reuse.

default: does not generate any configuration so the default nevisProxy behavior will apply.
disabled: the TCP connection is closed after use, and a new connection will be established for the next request.
enabled: the TCP connection is put in a pool so that it can be reused by future requests.

Limiting factors are Connection Pool Size, By Client, Inactive Interval, and Lifetime.

Only applies when this pattern is assigned to a Service (backend application), not when assigned to a Virtual Host.

Connection Pool Size

Maximum number of pooled TCP connections.

A TCP connection is only put in the pool if the size of the pool does not exceed the configured size.

By leaving this setting empty, you will be using the nevisProxy default value of 50.

For performance reasons, we do not recommend configuring a size bigger than 300.

Only applies when this pattern is assigned to a Service (backend application), not when assigned to a Virtual Host.

By Client

Forces TCP connections to only be reused for the same client. A call from a different client will use another TCP connection from the connection pool. If set to default, the nevisProxy default will be used.

Only applies when this pattern is assigned to a Service (backend application), not when assigned to a Virtual Host.

Inactive Interval

Inactivity duration allowed before a TCP connection is dropped. By leaving this field empty, you will be using the nevisProxy default value.

Only applies when this pattern is assigned to a Service (backend application), not when assigned to a Virtual Host.

Lifetime

The absolute lifetime of a TCP connection. This should be configured to less than the connection lifetime allowed by the firewall between nevisProxy and the content providers. By leaving this field empty, you will be using the nevisProxy default value.

Only applies when this pattern is assigned to a Service (backend application), not when assigned to a Virtual Host.

URL Handling

#Application Protection #Add-ons

Use the pattern to:

redirect requests (returning status code 302 with a Location header)
rewrite the path of a request, that is, forward.

Query parameters are always considered.

You can use the pattern as an add-on for Virtual Host or any application, for example, Web Application, REST Service, SOAP Service.

Redirect and forward rules have the following format:

<source> -> <destination>

The pattern generates a nevisProxy RewriteFilter named URLHandler_<name>. If either source or destination starts with http:// or https:// then the init-param RequestURL is set, otherwise RequestPath is used.

Redirect Rules

Terminate requests by returning a HTTP Redirect (status code 302).

In the first column (source) enter the current location. In the second column enter the destination to redirect to.

The following formats are supported:

URL
absolute path (starting with /)
relative path

Regular expressions are supported in the source, and group extractions may be used in the destination.

Absolute paths always point to the host, while relative paths are appended to the path of the assigned host (/) or application.

In order to redirect the context root of an application, leave the Key field empty.

The order of the rules matters. Only the first matching rule is applied.

Examples:

Source	Destination	Description
`http://(.*)`	`https://$1`	redirects plain HTTP to HTTPs, preserving the request path
`(.*)?lang=de`	`de/$1`	put query parameter into request path
`/nevis.html`	`https://www.nevis.ch`	redirect requests to a certain HTML page to a different domain

Forward Rules

Rewrite the path of HTTP requests.

Rewrites are done using a forward which means that they are transparent for the caller.

The format is the same as in Redirect Rules.

Apply only to sub-paths

Set to apply this pattern on some sub-paths only.

Sub-paths must be relative (e.g. not starting with /) and will be appended to the frontend path(s) of the virtual host (/) or applications this pattern is assigned to.

Sub-paths ending with / are treated as a prefix, otherwise an exact filter-mapping will be created.

The following table provides examples to illustrate the behavior:

Frontend Path	Sub-Path	Effective Filter Mapping
`/`	`secure/`	`/secure/*`
`/`	`accounts`	`/accounts`
`/`	`api/secure/`	`/api/secure/*`
`/`	`api/accounts`	`/api/accounts`
`/app/`	`secure/`	`/app/secure/*`
`/app/`	`accounts`	`/app/accounts`
`/app/`	`api/secure/`	`/app/api/secure/*`
`/app/`	`api/accounts`	`/app/api/accounts`

Apply Only Conditionally

Configure one or more conditions under which the configured rules should be triggered. Multiple conditions are combined with logical AND.

In the first column enter the key, for example ENV:REQUEST_URI. In the second column enter the regex which has to match, for example: .*\.js$.

Filter Phase

The phase when this filter should be applied depends on your use case.

use START when the redirect / rewrite should be done as early as possible.
use AFTER_SANITATION to redirect / rewrite after validating the request.
use AFTER_AUTHENTICATION to redirect / rewrite after authentication.

Virtual Host

#Application Protection #Virtual Hosts

The pattern represents a virtual host of a nevisProxy Instance, reachable on one or more Frontend Addresses.

In Kubernetes deployment, an Ingress or Gateway API controller terminates TLS connections towards nevisProxy.

A virtual host can provide access to various applications and services.

To act as reverse proxy for applications, add a Web Application, REST Service, or SOAP Service pattern, and reference this virtual host.

To provide authentication, use the OAuth 2.0 Authorization Server / OpenID Provider or the SAML IDP pattern.

The pattern supports IP-based, port-based, and name-based virtual hosting. Name-based virtual hosting with HTTPs requires server name indication (SNI).

Basic Usage

Define the addresses under which the host is reachable using Frontend Addresses.

The addresses must be fully qualified, they have to they have to start with http:// or https://.

You can define multiple addresses and you can mix HTTP and HTTPs, as long as you do not use more than one port for each protocol.

Examples:

Frontend Addresses: https://www.siven.ch
Frontend Addresses: https://www.siven.ch http://www.siven.ch http://partners.siven.ch
Frontend Addresses: https://www.siven.ch:8443 http://www.siven.ch:8080 http://partners.siven.ch:8080

The pattern is required for all nevisProxy instances, even those having only one frontend address.

Listening on Internal Addresses

Set Bind Addresses to make the host listen on addresses (DNS host names or IPs and ports) other than the configured frontend addresses.

Supporting both HTTPS and HTTP

To expose a host using HTTP and HTTPS, specify the two schemas in Frontend Addresses:

Frontend Addresses: https://www.siven.ch http://www.siven.ch

Name-based Virtual Hosts

With name-based virtual hosting, the server relies on the client to report the hostname as part of the HTTP headers. Using this technique, many different hosts can share the same IP address.

To configure name-based virtual hosts, set the Frontend Addresses to the virtual name(s) of the host and set the Bind Addresses to the physical addresses of the host.

For example, to set up a two virtual hosts to be reachable on the same internal address IP and port but with different public host names, configure as follows:

Frontend Addresses: https://www.siven.ch http://www.siven.ch
Bind Addresses: https://0.0.0.0:8443 http://0.0.0.0:8080

Then configure another virtual host to use the same Bind Addresses but different Frontend Addresses:

Frontend Addresses: https://partners.siven.ch http://partners.siven.ch
Bind Addresses: https://0.0.0.0:8443 http://0.0.0.0:8080

Note: name-based virtual hosts using HTTPS requires all clients supporting SNI.

nevisProxy

Assign the nevisProxy Instance this virtual host should be assigned to.

Frontend Addresses

Define addresses (HTTPS or HTTP) at which this host will be reachable from a client perspective.

The basic syntax is:

<scheme>://<hostname>
<scheme>://<hostname>:<port>

A variable may be used to define different addresses for different stages (for example, DEV, TEST, PROD).

For placeholders, use a marker name containing at least one ASCII letter; digits, underscores, and hyphens are also allowed. You may optionally surround the marker name with @@, for example https://login.placeholder://@@WASL_DOMAIN@@. Bare markers are also supported; they end at the first character outside the marker-name character set. The placeholder:// prefix is removed during generation, and the CI/CD pipeline must replace the remaining marker before deployment. Do not use downstream template expressions or a complete unresolved URL such as placeholder://https://login.example/issuer.

Placeholder support was originally introduced for LTS26. These enhancements are experimental. Support is not universal: patterns that require a concrete URL object or a resolvable frontend address may still report a targeted validation error.

Placeholders are currently supported only by settings whose consumers explicitly forward the unresolved text. URL settings that need a concrete host, port, path, query, TLS decision, routing decision, or bind address remain unsupported. HostPort placeholders are supported only where the complete host-and-port value is forwarded opaquely, such as database hosts and the NevisAuth connection host. Selection, numeric, path, duration, map, pattern reference, and attachment settings remain unsupported.

The expression ${deployment_host} may be used when the name of the target host is required.

Examples:

http://www.siven.ch
https://www.siven.ch
http://${deployment_host}:8080

The port will, if omitted, default to 443 for HTTPS and to 80 for HTTP.

Bind Addresses

The physical address(es) to bind on, with scheme HTTP or HTTPS and ports.

Must be set when multiple virtual hosts should listen on the same endpoint (name-based virtual hosts).

If not set the Frontend Addresses will be used to bind.

The host name must resolve to an IP which is bound to a network interface.

You can also use 0.0.0.0 for the host name to listen on all network interfaces.

Examples:

https://www.siven.ch:8443
http://localhost:8080
https://192.168.1.1:443
http://0.0.0.0:80

Root URL Redirect

Set to redirect requests for the root path (/) to an absolute path or a full URL.

Hosted Resources

Upload a ZIP to provide your own resources.

By default, the following resources are provided:

/favicon.ico
/index.html
/errorpages/403.html
/errorpages/404.html
/errorpages/500.html
/errorpages/502.html
/resources/logo.png
/resources/bootstrap.min.css
/resources/default.css

This host has its own error handler (ErrorHandler_Default) which is assigned to the root location (/*). The error handler will replace the response body when an HTTP error code occurs and an error page is available.

Error pages for HTML must be added the sub-directory errorpages and named <code>.html.

The error code is returned to the caller as this may be required by some REST clients.

If you do not want this you can assign a specific HTTP Error Handling pattern to this Virtual Host or to applications via Additional Settings.

The servlet hosting the above resources is usually mapped to the root location (/*), however if there is already another servlet mapped there, the servlet is mapped to individual root files and directories.

If there is an undesired mapping, it can be deleted by removing the given resource from the zip file.

Session Store

Assign a nevisProxy Remote / Hybrid Session Store pattern here if you want to store sessions in a remote session store.

A remote session store must be used when the nevisProxy instance is deployed with redundancy and there is no sticky load balancer in front.

Frontend Key Store

This setting specifies the key store used for the HTTPS endpoint.

The certificate in the key store must be valid for all frontend addresses. If there are multiple frontend addresses, you have to ensure that the certificate has Subject Alternative Name (SAN) entries for all of them.

If no pattern is assigned, automatic key management will provide a key store.

Frontend Trust Store

Configure a trust store to validate client certificates for incoming connections.

The trust store may contain an arbitrary number of CA certificates issuing these client certificates.

Caution: additional configuration is required to enforce client cert authentication.

Choose between the following options:

Authenticate against a user that has a Certificate credential in nevisIDM.
- Use the nevisIDM Client Certificate Authentication pattern in your authentication flow, ideally at the beginning of the flow.
- The pattern will patch the IdentityCreationFilter by adding the init-param ClientCert. This leads to an additional handshake to request a client certificate.
Enforce client certificate authentication for the entire host.
- Use the Generic nevisProxy Settings pattern to set the required attributes of the Connector element.
- Refer the documentation of nevisProxy frontend connectors for further information.

Frontend TLS Settings

Choose between:

modern: allows TLSv1.3 only.
intermediate: allows TLSv1.2 and TLSv1.3,
custom: assign a Generic nevisProxy TLS settings pattern via Additional Settings and provide the TLS settings there.

The following legacy options are provided to replace options that existed in pattern version < 9.2605.

legacy recommended: replaces the previous default of recommended.
legacy compatible: replaces the option compatible.

The cipher configuration is generated based on the enabled protocols automatically. If you need different ciphers, select custom, assign a Generic nevisProxy TLS Settings pattern, and configure the Cipher Suite there.

Client Authentication

Choose from:

disabled (default): No client certificate is required to connect to this virtual host.
enabled: Clients must present a client certificate signed by a CA.

The CA which has issued the client certificate must be part of the Frontend Truststore. When no client certificate is presented or the certificate is not valid the connection will be aborted. As no error page is rendered this feature is not recommended when there are browser-based clients. Use for technical clients only.

Unsecure Connection

This property defines how to handle requests received via plain HTTP. Choose between:

redirect If a request is received via plain HTTP the client is redirect to the HTTPS endpoint (requires a Frontend Address with scheme https://).
allow the request is processed.

Qos Configuration (mod_qos)

nevisProxy uses the mod_qos module to ensure quality of service (QoS). Choose between:

off: the module is disabled on this virtual host.
standard: provides a default configuration which protects against common denial of service (DoS) attacks.
custom: configure Generic mod_qos Configuration via Additional Settings.

Allowed HTTP Methods

Define the HTTP methods which are allowed on this virtual host.

The setting default (complete) is quite relaxed as it enables most methods. Only two are excluded:

CONNECT: no use case of nevisProxy.
TRACE: may be useful for debugging but can be a security vulnerability.

If you do not have any applications using WebDav select basic.

The allowed HTTP methods can be restricted further in application patterns.

For more fine-grained control you may use Generic nevisProxy Instance Settings to overwrite the allowedMethods (see pattern help for details).

OWASP ModSecurity CRS Version

Allows to select the OWASP ModSecurity CRS version.

Available options are:

4.22.0: newest version of CRS, uses Anomaly Scoring Mode, minimal CRS setup
3.3.8: default and recommended setup, uses Anomaly Scoring Mode
custom: allows to upload a custom rule set. See the ModSecurity Rule Set option for more information.

ModSecurity Rule Set

Upload a .zip file containing configuration for ModSecurity. The .zip must contain a configuration file called modsecurity.conf.

The modsecurity.conf file will be included for all Web Application patterns which have Request Validation set to standard, custom, or log only.

Click Download Default Configuration to download the default configuration which is applied when no .zip is uploaded. There is one link per provided OWASP ModSecurity CRS Version.

Security Response Headers

Configure security response headers:

off does not set any security headers
basic sets default headers on responses. That is:
- Strict-Transport-Security: max-age=63072000
- X-Content-Type-Options: nosniff
- Referrer-Policy: strict-origin-when-cross-origin
custom configure Security Response Headers via Additional Settings

Session Store Resource

Exposes the REST interface of the session store servlet on the given path. For security reasons, only DELETE requests are allowed and assigning an access restriction pattern is recommended.

Before setting this parameter, make sure that there will be an actual session store servlet.

Session Store Access Restriction

Assign an access restriction patterns to prevent unauthorized access to the REST interface of the session resource.

HTTP/2 Support

Enables the support of HTTP/2 for incoming connections on this nevisProxy virtual host.

Note that mod_qos has limited support for HTTP/2, therefore only request level directives are supported if enabled.

Early Hints

Enables the HTTP/2 feature of early hints.

Configures early hints with the Apache directive H2PushResource

It will send out a "103 Early Hints" response to a client as soon as the server starts processing the request.

Static Cache

Add a Static Content Cache pattern to the Virtual Host.

Use it to cache the early hint resources as static content in nevisProxy to further increase the performance. Map the Static Content Cache pattern to the same paths as the Early Hints parameter.

Gateway API Generation

To make a Virtual Host accessible from outside the Kubernetes cluster, you need a Gateway API or Ingress controller.

Support for Gateway API was introduced in pattern version 8.2511.3 and is the default for 9.2605.x and later. Versions <= 8.2511.x use NGINX Ingress as the default controller. This is also to avoid a breaking change and manual cleanups.

Choose the controller type by setting the following inventory variables:

__nevisadmin_ingress_enabled
__nevisadmin_gateway_api_enabled

Only one of these variables should be set to true. You can also disable the generation entirely by setting both variables to false.

The patterns then generate a NevisIngress or NevisGateway resource for each Virtual Host. During reconcile, the Nevis Operator component produces a standard Ingress or Gateway resource for the selected controller.

This setting applies only when __nevisadmin_gateway_api_enabled is true and allows disabling generation of the NevisGateway resource for this host.

When disabled, any Gateway API Settings pattern assigned to the host will be ignored.

Gateway Host

Hostname used for Envoy Gateway routing, configured on the Gateway listener and the generated NevisGateway's hostnames.

Use only when a downstream component (e.g. a CDN or edge proxy) rewrites the Host header before the request reaches the Gateway API controller, so the incoming request no longer carries the domain the browser originally used. Enter the domain the request arrives with once rewritten.

When set, the Host header forwarded to nevisProxy is restored to the value configured via Frontend Addresses. Leave this empty if no downstream component rewrites the Host header.

Ingress Generation

To make a Virtual Host accessible from outside the Kubernetes cluster, you need a Gateway API or Ingress controller.

Choose the controller type by setting the following inventory variables:

__nevisadmin_ingress_enabled
__nevisadmin_gateway_api_enabled

Only one of these variables should be set to true. You can also disable the generation entirely by setting both variables to false.

This setting applies only when __nevisadmin_ingress_enabled is true and allows disabling generation of the NevisIngress resource for this host.

When disabled, any NGINX Ingress Settings pattern assigned to the host will be ignored.

Host

Set a value for the nginx.ingress.kubernetes.io/upstream-vhost annotation.

Ingress uses this when forwarding the request to the nevisProxy service, as Host header.

This setting is used in Nevis ID but may be useful in other deployment scenarios as well.

Use when requests are terminated in front of the ingress and the Host header sent by the user agent is replaced.

Enter a value that matches the Frontend Addresses.

TLS Secret

Set a custom value for the TLS secret used for the ingress host.

Reserved for usage in Nevis ID.

Source IP Header

If set, the source IP for the request will be taken from the configured request header.

Set this in environments where the request is terminated in front of nevisProxy.

For instance, when deploying to Kubernetes, ingress usually terminates the request.

You have to make sure that the request header value is correct and cannot be spoofed.

Allow Private IP Addresses

By default, when a private IP address (e.g. 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) is found in the Source IP Header, it is rejected as suspicious, and the connecting proxy's own IP address is used instead. This is usually a sign of a misconfiguration.

Enable this option if your clients may connect from private IP address ranges.

When enabled, private IP addresses received in the Source IP Header are accepted as the client's real IP address. Note that such clients will not have geolocation data, since private IP ranges cannot be mapped to a country.

Only enable this together with a configured Source IP Header, and only when its value can be trusted.

Encoded Slashes

Choose from:

allowed: URLs containing encoded slashes are allowed and will not be decoded (AllowEncodedSlashes NoDecode).

Also URLEncoding will be set to false for each HttpsConnectorServlet.

forbidden: URLs containing encoded slashes will be denied and a 404 will be returned.

This is the default behavior of Apache.

Additional HTTP Status Codes

Allow non-standard HTTP status codes.

The configuration of additional status codes is required, for example, when using WebDav (HTTP status code 207 is used by WebDav).

Trailing Slash Redirect

nevisProxy generates redirects to the same resource with a / appended, in case a servlet mapping only matches, when the trailing / is present.

Additional Settings

Assign add-on patterns to customize the behavior of this virtual host.

Web Application

#Application Protection #Applications

Using the pattern, you can set up access to a web application on a nevisProxy Virtual Host.

Virtual Host(s)

Assign Virtual Host patterns which shall serve as entry point for this application.

Frontend Path(s)

Enter the path(s) where this application shall be accessible on the assigned Virtual Host.

It is recommended to set only 1 path. Examples:

/app/ - defines a base path.

Requests which have a path component starting with /app/ will be sent to this application. This is the most common scenario.

/ - may be used when there are no other applications.

The Hosted Resources of the Virtual Host are still accessible but all other requests will be sent to the backend application.

exact:/app.html - matches requests to /app.html only (query parameters may also be added).

Use for single-page applications which do not require any additional resources.

prefix:/app - matches requests which have a path component matching /app*/*.

Examples: /application/, /app/index.html, /app2/secure/

In case the frontend path is different from the path used within Backend Addresses then the path will be rewritten in incoming requests.

Note that for response by default only the headers are rewritten. See Response Rewriting for further options.

Note that when you enter multiple paths there are some limitations:

Filters created by a Realm or Additional Settings will be mapped to all paths.
The paths have to be the same on the backend server.

Authentication Realm

Optionally assign a realm to protect this application or service.

Application Access Token

Propagate a token to the backend application. The token informs the application about the authenticated user.

For instance, assign Nevis SecToken if the application uses Ninja or SAML Token for applications which are able to consume SAML Responses.

Additional Settings

Assign add-on patterns to customize the behavior of this service.

Example use cases:

Authorization Policy to enforce roles or an authentication level.
URL Handling to redirect or forward requests.
HTTP Header Customization to add, replace, or remove HTTP headers in requests or responses.

Backend Addresses

Enter the complete URLs (scheme, host, port and path) of the backend services.

Note:

all URLs must use the same scheme and path.
automatic path rewriting will be performed when the path differs from the Frontend Path.

In case you are setting multiple addresses, use Load Balancing to select a request dispatching strategy.

Load Balancing

Select a request dispatching strategy when several Backend Addresses are configured.

disabled - all requests will be sent to the first address. If this address is not available the next address is chosen;
round-robin - one of the addresses will be picked up for each request using a round-robin rotation;
session-sticky - one of the addresses will be picked up for each new session using a round-robin rotation, then subsequent requests for the session will be sent to the same address.

Failover strategy:

When the selected backend cannot be accessed, nevisProxy will attempt to use another one.
Once the said backend can be accessed again, it can be picked up for new requests if the load balancing is round-robin, or for new sessions if the load balancing is disabled or session-sticky.

The requests linked to an existing session will still go to the current backend until the end of the session if the load balancing is disabled or session-sticky.

Key Store

Optional setting to use a client certificate for connecting to HTTPS backends.

Send Certificate Chain

Choose which certificates are sent to the backend during mutual authentication:

disabled: Send the client certificate from the Key Store;
enabled: Send the certificate chain from a PEM Key Store or a nevisKeybox Store.

The certificate chain file must contain the client certificate and the intermediate CA certificates.

Trust Store

Optional setting for enabling trust to HTTPS backends.

For securing production environments:

set Backend Addresses starting with https://
assign a Trust Store pattern containing the certificates required for verifying the backend certificate
set Hostname Validation to enabled

Hostname Validation

Enable to verify that the hostname on the certificate presented by the backend matches the hostname configured in Backend Addresses

Host Header

Defines the Host header for requests forwarded to the application.

When client is selected then nevisProxy will keep the Host header as received from the client. The following init-param will be generated:

<init-param>
  <param-name>HostName</param-name>
  <param-value>ENV:HTTP_Host;</param-value>
</init-param>

Response Rewriting

Enable to replace backend host names in responses or set to custom for complex rewriting use cases.

off - disables automatic response rewriting
header - enables auto rewrite for response headers (including Set-Cookie header)
complete - enables auto rewrite for the entire response (including body)
custom - requires assignment of Response Rewriting Settings via Additional Settings

Outbound Client Authentication

Controls whether the service access presents a client certificate on outbound TLS connections.

CSRF Protection

Cross-Site Request Forgery (CSRF) is an attack to force an authenticated user to send unwanted requests.

off (default) - no CSRF protection. Recommended for applications which may be called from other sites.
header-based - GET and HEAD requests are allowed (assumption: these methods must not manipulate server-side state).

For other requests the Referer and Origin headers must match the Host header.

Request Validation (ModSecurity)

off - no request validation
standard - uses ModSecurity OWASP Core Rule Set (CRS) with default paranoia level 1 - Basic security
custom - configure Request Validation Settings via Additional Settings
log only - uses standard in log only mode

Allowed HTTP Methods

Define the HTTP methods allowed for this application.

Methods which are listed here must also be allowed on the Virtual Host.

You may also use the following method groups:

ALL-HTTP includes common HTTP methods.

These are: GET, POST, HEAD, DELETE, TRACE, CONNECT, OPTIONS, PUT, PATCH
ALL-WEBDAV includes all methods required for WebDAV.

These are: MERGE, UNCHECKOUT, MKACTIVITY, PROPPATCH, LOCK, CHECKOUT, SEARCH, COPY, MKCOL, MKWORKSPACE, PROPFIND, UPDATE, REBIND, BASELINE-CONTROL, UNBIND, CHECKIN, VERSION-CONTROL, UNLOCK, LABEL, MOVE, ACL, BIND, REPORT

To remove methods from ALL-HTTP and ALL-WEBDAV simply add the method with a - sign in front of it.

Session Termination

Use this feature to terminate sessions on the backend application.

nevisProxy will send a GET request to this path when the nevisProxy session is terminated (due to logout or session timeout).

Custom Parameters

Add custom init-param(s) for the Http(s)ConnectorServlet. For example: ConnectionRetries=10

WebSocket Support for Application

#Application Protection #Add-ons

The pattern enables WebSocket support for backend applications. Assign to your application using Additional Settings.

The pattern generates two additional servlets:

a WebSocketServlet named Connector_<application>_WS
a ServletMappingServlet which selects Connector_<application>_WS when the HTTP Header Upgrade contains the value websocket

The TCP connection is reserved for each WebSocket connection.

Custom Parameters

Add custom init-param for the WebSocket servlet.

Please check the nevisProxy technical documentation for supported init-params of the servlet class ch::nevis::isiweb4::servlet::connector::websocket::WebSocketServlet.

Access Restriction​

Listing Type​

Source IPs​

Source IP HTTP-Header​

Country Database File​

Country Database URL​

Rules​

Default Action​

Apply only to sub-paths​

Allow Override​

Custom GeoLocation Lookups​

Country Database Download Periodicity​

Cookie Customization​

Client Cookies​

Shared Protected Cookies​

Protected Cookies​

Cookie Conflict Resolution​

CSRF Protection Settings​

SameSite Cookie (Experimental)​

Header-based Check​

Allowed Domains​

Generic Application Settings​

Filters and Mappings​

Filter Mappings​

Filter Phase​

Servlets and Mappings​

Template Parameters​

Remove Filter Mappings​

Generic nevisProxy TLS Settings​

Protocols​

Cipher Suite​

SSL Options​

Generic Virtual Host Settings​

Filters and Mappings​

Filter Mappings​

Filter Phase​

Servlets and Mappings​

Template Parameters​

Remove Filter Mappings​

Mime-Mappings​

Geolocation Service​

Virtual Host(s)​

Frontend Path​

Geolocation Database​

Authentication Realm​

Additional Settings​

gRPC Service​

Virtual Host(s)​

Frontend Path(s)​

Authentication Realm​

Application Access Token​

Additional Settings​

Backend Addresses​

Key Store​

Trust Store​

Hostname Validation​

Host Header​

Outbound Client Authentication​

Allowed HTTP Methods​

Custom Parameters​

Hosting Service​

Virtual Host(s)​

Frontend Path​

Resources​

Default File​

Authentication Realm​

Rewrite Rules​

Additional Settings​

HTTP Error Handling​

Error Pages​

Blocked Status Codes​

Redirect Status Code Mapping​

Keep Header Status Codes​

Overwrite Status Codes​

Mode​

Apply only to sub-paths​

Content-Type Mode​

Content-Types​

Base Path​

Keep Security Headers​

Access Restriction

Listing Type

Source IPs

Source IP HTTP-Header

Country Database File

Country Database URL

Rules

Default Action

Apply only to sub-paths

Allow Override

Custom GeoLocation Lookups

Country Database Download Periodicity

Cookie Customization

Client Cookies

Shared Protected Cookies

Protected Cookies

Cookie Conflict Resolution

CSRF Protection Settings

SameSite Cookie (Experimental)

Header-based Check

Allowed Domains

Generic Application Settings

Filters and Mappings

Filter Mappings

Filter Phase

Servlets and Mappings

Template Parameters

Remove Filter Mappings

Generic nevisProxy TLS Settings

Protocols

Cipher Suite

SSL Options

Generic Virtual Host Settings

Filters and Mappings

Filter Mappings

Filter Phase

Servlets and Mappings

Template Parameters

Remove Filter Mappings

Mime-Mappings

Geolocation Service

Virtual Host(s)

Frontend Path

Geolocation Database

Authentication Realm

Additional Settings

gRPC Service

Virtual Host(s)

Frontend Path(s)

Authentication Realm

Application Access Token

Additional Settings

Backend Addresses

Key Store

Trust Store

Hostname Validation

Host Header

Outbound Client Authentication

Allowed HTTP Methods

Custom Parameters

Hosting Service

Virtual Host(s)

Frontend Path

Resources

Default File

Authentication Realm

Rewrite Rules

Additional Settings

HTTP Error Handling

Error Pages

Blocked Status Codes

Redirect Status Code Mapping

Keep Header Status Codes

Overwrite Status Codes

Mode

Apply only to sub-paths

Content-Type Mode

Content-Types

Base Path

Keep Security Headers