Application Mapping, Paths, Preconditions

vWAF uses several “layers” to determine which ruleset and which rules to apply when analyzing a particular request. This gives you much flexibility and maximum control.

To keep your security configuration simple and easy to maintain, it’s important that you fully understand these layers and how vWAF processes a request.

The enforcers of vWAF run as plug-ins in your web servers. You can configure each enforcer so that it sends a special key along with each request to the decider. The decider, which processes your rulesets, can then use this key to handle requests that came in via different web servers differently.

If you need to set up your own customer key, you can do so within TrafficScript by setting the “enforcer.location” variable using the following command connection.data.set("enforcer.location“, “my-special-customer-key").

For details on setting up a customer key for mapping requests to a particular application and ruleset, see Editing Application Mapping.

In vWAF, so-called “applications” are a collection of rulesets for a particular purpose. An application typically consists of a detection ruleset, a protection ruleset, and a loaded ruleset. Also the application includes the full history of these rulesets. In addition, there are some application-specific settings that are not stored in the rulesets but for the application as a whole.

Applications in vWAF are not necessarily identical with the web applications that you want to protect. Several of your web applications may be handled by the same application in vWAF. But there may also be several applications in vWAF that handle distinct parts of a single web application.

In the navigation area of vWAF, the set up applications appear in alphabetic order.

For more information on applications, see Editing Applications.

Hosts in vWAF are your network or Internet hosts, such as www.demo.com, demo.com, demo.com:80, localhost, 127.0.0.1, and so on.

For details on specifying your hosts in vWAF, see Editing Application Mapping.

Prefixes are typically defined when you have different web applications on the same host, such as www.demo.com/shop and www.demo.com/blog. You can then set up different prefixes in vWAF, such as /shop and /blog.

In Application Mapping, you can map these prefixes to different applications. The result is that vWAF applies other rulesets to what’s below /shop than to what’s below /blog.

If you don’t need distinctions like this, you can simply ignore the prefix settings. By default, vWAF then uses an “[Empty Prefix]”, which matches everything. In the example, vWAF would then simply apply the same rulesets to everything below www.demo.com.

For information on setting up prefixes, see Editing Application Mapping.

Application mapping maps your applications, and thus your rulesets and settings, to customer keys, hosts, and prefixes. When the decider receives a request via the enforcer, the application mapping determines which application matches this request’s customer key, host, and prefix. The decider then uses this application’s active protection ruleset and/or detection ruleset for processing the request.

In the administration interface, application mapping settings look like this:

If, for example, a request to http://www.shop.biz/myprefix02/somepath/comes in, application webshop matches. vWAF then uses the rulesets of application webshop for processing the request.

For details on setting up application mapping, see Editing Application Mapping.

Application mapping determines which application and thus which rulesets vWAF uses for processing a particular request. Paths provide one more level of distinction.

Unlike application mapping, paths have nothing to do with the process of deciding which ruleset to apply, but provide a distinction within a ruleset.

When analyzing a request, it depends on your definitions of prefixes, which part of the URL is tested against the configured application paths. The considered path is the remainder after a matching prefix. For example, imagine a request to http://www.mysite.com/what/ever:

Other than a prefix, a path is specified by a regular expression. This means that one path can match multiple directories, directory trees, and pages.

The default path specification is .*, which means “everything”. For details on the syntax of supported regular expressions, see Regular Expressions.

In the user interface, paths are defined as part of the ruleset of an application.

You can add handlers to the path. Other than handlers added directly to the application, handlers added to a path are only executed if this particular path is part of a request. This enables you to refine your rulesets for specific parts, pages, or file types of your web application.

Paths are processed from top to bottom. You can change the order within the administration user interface.

Another feature of paths is the ability to make the execution of handlers depend on certain preconditions. For each path you can define one or more of such preconditions. Only when all preconditions defined for a path are met at the same time, vWAF implements the handlers defined for the path.

Paths and preconditions enable you to set up very advanced configurations.

For example, if you’re using preconditions, you can create a duplicate of a paths and only define preconditions for one of the two instances of the path. This means that you can handle the path in a different way, depending on whether or not the preconditions are met.

If you actually don’t want to differentiate between different paths but want to use preconditions for some of your universal handlers, you can use the default “catch-all” path.* and add these handlers and preconditions there.

For details, see Editing Paths and Editing Preconditions.

The following example illustrates the scenarios that are possible when combining the configuration layers of customer keys, applications, hosts, prefixes, and paths.

Imagine you’re a provider who operates web shops, online communities and corporate web sites. Here’s the setup for two of your clients:

vWAF processes all application mappings and paths from top to bottom. (You can change the order via the administration user interface.)

Based on this configuration, vWAF would act as follows:

When deleting an application in application control, there might still be mappings defined for this application. In this case, when deleting the application you’re asked whether you want to keep the mapping. If you keep the mapping of a deleted application, the mapping is listed with the application name “[Deleted Application]” in Application Mapping. Mappings like this are still used in request processing! As there’s no corresponding application and thus no corresponding ruleset, requests that match this mapping always result in a no configuration found entry in the log files and are denied.