Application Mapping, Paths, Preconditions

Prefixes

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.

Paths and preconditions

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:

• If your application mapping defines a prefix /what, then /ever is compared to your path definitions
• If your application mapping doesn’t define any prefix /what, then /what/ever is compared to your path definitions

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.

How it all works together

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

In reality, configurations may be much more complex—or much simpler. Using customer keys, prefixes, and paths is optional. If you don’t specify customer keys, vWAF handles all requests as if they were using the same empty customer key, shown as “[Default Customer Key]” in the user interface. If you don’t specify prefixes, vWAF uses an empty prefix, which matches any URL. If you don’t specify paths, this doesn’t affect which application is used, but you simply can’t add any path-specific preconditions.

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:

• A request to shop.provider.com sending the customer key luckycorp would be processed by the rulesets for the application shop-lucky.
• A request to shop.provider.com sending the customer key happycorp would be processed by the rulesets for the application shop-happy.
• Requests to forum.provider.com and to members.provider.com would always be processed by the rulesets for the application community. (Note that this application is mapped to both customer keys.)
• Requests to www.behappy.com/public/something would be processed by the rulesets for the application special01. For example, this could be a request to www.behappy.com/public/ index.html or a request to www.behappy.com/public/somedir/someotherdir/onemoredir/ somepage.php.

  The same applies if letssmile.com is used instead of behappy.com:

  Requests to www.letssmile.com/public/something would be processed by the rulesets for the application special01. For example, this could be a request to www.letssmile.com/public/ index.html or a request to www.letssmile.com/public/somedir/someotherdir/onemoredir/ somepage.php.

• Requests to www.behappy.com/internal/something would be processed by the rulesets for the application special02. For example, this could be a request to www.behappy.com/ internal/index.html or a request to www.behappy.com/internal/somedir/someotherdir/onemoredir/somepage.php, but also to www.behappy.com/internal/secret/index.html or to www.behappy.com/internal/topsecret/index.html.

  Note that the settings for paths don’t affect which application and thus which rulesets are used. Actually the path definitions as given in the table are part of the rulesets of the application special02. You can use the paths to add additional preconditions and additional handlers that are applied only if one of the matching URLs is used. For example, this way you could add some extra rules that are used on a request to www.behappy.com/internal/secret/subdir/ or some other extra rules used on a request to www.behappy.com/internal/topsecret/subdir/. Anything else is covered by the path .*, which is the regular expression for “everything”. As this path stands below the other two paths in the list, it’s only applied if none of the other two paths matches.

• All other requests, no matter to which host and URL, would be processed by the rulesets for the application catch-all. For example, requests to www.behappy.com/index.html or to www.letssmile.com/whatever/ would be processed this way.

• Also a request to shop.provider.com:80 would be mapped to the catch-all application. (Note that shop.provider.com and shop.provider.com:80 are not the same host and that shop.provider.com:80 isn’t mapped to any other application.)

The application catch-all stands below the other applications so that it’s only used when no other mapping matches. If it stood on top, it would always match and the other mappings would actually never be used.

Mappings of deleted applications

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.

You can still export the settings of a mapping with a deleted application and later import them for another mapping.