Baseline Protection Handler
Purpose
The Baseline Protection Handler implements the rules that have been created by the Baseline Protection Wizard. If a request matches one of the given patterns, vWAF denies the request with a configurable error code.
In most cases, you do not need to edit this handler manually. However, you can fine tune settings if needed; for example, if too many false positives occur in detection mode.
For more information regarding adding and editing Handlers, see Editing Handlers.
For more information regarding Baseline Protection, see Baseline Protection and Configuring and Updating Baseline Protection.
Severity
The severity of the events triggered by this handler depends on the particular rule that the handler applies. To review each rule and the corresponding severity, click Show Rules. If several rules match a request, the one with the highest severity determines the severity.
(For details on severity levels, see Severity of Events Triggered by Handlers).
Recommendations for use
This handler is configured automatically by vWAF to provide Baseline Protection. This is achieved by a blacklisting mechanism that checks requests for known forms of attack.
If required, you can disable individual handler rules. Note that this does not delete rules; rules are managed and updated by vWAF. If required, you can also exclude requests that exceed a certain content size.
There are a number of specialized handlers that run similar or partial checks, but these usually provide a broader scope of functions. The order in which handlers are executed depends on the sequence in which the handlers are listed on the tabs Global Handlers / Handler Templates / Handlers of the administration interface. Handlers listed on top are always executed first. The order is fixed and cannot be changed.
Interaction with other handlers
The Baseline Protection Handler ignores arguments that have already passed the Whitelist Handler.
Attributes
Attribute | Meaning |
|---|---|
reject on zero byte | This helps protect your application against null byte injection attacks (where injection of null byte characters can alter user-supplied data and gain unauthorized access to system files). If enabled, arguments that include a zero byte are rejected. This check is applied for each decoding step, if 'multiple decoding' is enabled (see below). |
exclude from baseline check | The keys specified here are excluded from the Baseline Protection Handler ruleset. This allows you to exclude specific keys from the baseline check, such as a user-defined text field for example. Regular Expressions can be used. To remove a key, delete the entry in the Regex column. The key is removed when you save the handler updates. |
log all matching patterns | If a request is denied, vWAF logs the pattern (of the attack). This option instructs vWAF to continue to check the request against other attacks, despite identify an attack already. This option is not required or recommended in general. However, it maybe useful when testing a new application to check which rules produce false positives. During this testing phase, you may accept a trade performance at the expense of logging more results, to review and eliminate false positives. |
handle excluded args case sensitive | This determines whether or not arguments are treated as case insensitive or case sensitive. It is a global setting and applies to all arguments. Unless your baseline protection ruleset includes case sensitive arguments, it is recommended that this is set to case insensitive. However, if you require support for case sensitive arguments, you need to set this option to case sensitive. |
apply patterns to keys | By default, the Baseline Protection Handler checks the values of requests for the patterns given under rules, but not the keys. For example, if you have a request such as http://host/foobar?key1=value1&key2=value2, the Baseline Protection Handler checks value1 and value2. If you enable the option apply patterns to keys, the handler checks both values and keys. This may be important, for example, where a web application processes requests in the form: http://host/foobar?something. In this example, something is not recognized as a value but as a key; therefore, apply patterns to keys must be enabled to ensure something is checked. |
apply patterns to url parameter | By default, the Baseline Protection Handler does not check URL parameters, such as PARAMETER in the URL http://host.domain/path1;PARAMATER/path2?foo=bar. If you enable the option apply patterns to url parameter, the handler checks URL parameters. This option is only required if your application uses URL parameters. If you do not use URL parameters, it is recommended that the option is disabled. |
max variable size | This determines the upper limit for the variable size. If the variable size of a request is greater than this value, vWAF does not check the request for the given patterns. Checking requests with a variable size of more than 10KB can have a negative impact on performance. The value is entered in Bytes and the default is 2048. |
reject if oversize | If enabled, vWAF denies a request if its variable is bigger than max variable size. |
oversize key exclusion list | Optional: This is only applicable if reject if oversize is enabled. If reject if oversize is enabled, vWAF denies a request if its variable is bigger than max variable size. However, the oversize key exclusion list allows you to specify keys that are exempt from the max variable size limit. This may be required to allow specific large uploads, for example. Regular Expressions can be used. If configuring these options, it is recommended that before you activate your ruleset in protection mode you first run the application in detection mode to gather enough information to evaluate the log files and to confirm that the settings are not denying valid requests. To remove an entry, delete the entry from the edit field. The entry is removed when you save the handler updates. |
multiple decoding | vWAF is able to detect multiple encoding evasion attempts. The values specified in the Decoding Steps column determine how many times vWAF attempts to decode the specified arguments, headers, and URIs requests. After each decoding, vWAF applies the rules once more. The check continues until one of the rules match or when the handler has processed all Decoding Steps without finding a match. If the Reject option is enabled, vWAF attempts to decode one more time. If decoding is possible and the decoded data differs from previous attempts, vWAF denies the request (without further checks). The more decoding steps, the more processing time is required. To avoid a negative impact on performance, only specify the maximum number of steps required for your web application. |
match timeout | Determines the maximum amount of time (in milliseconds) that vWAF processes each rule. If pattern matching takes longer than the specified time, vWAF aborts the check. The default value is 100 ms. If a check is aborted due to exceeding the match timeout time, the next action depends on the attribute reject if match timeout settings:
|
reject if match timeout | Determines whether requests are denied if pattern matching takes longer than the match timeout allows. |
categories | Defines the types of attacks that are covered by baseline protection. Each baseline rule belongs to one of these categories. In order to simplify the ruleset and to optimize performance, you can disable a category provided your web application is not vulnerable to this kind of attack, or you configured other handlers to provide adequate protection. Depending on your category selections, particular rules are automatically removed from the rules list. |
tags | If your web application does not use a particular technology, you can select the relevant tag to remove all rules that are specific the particular technology. This simplifies the ruleset and optimizes performance; the appropriate rules are automatically removed from the rules list. Before disabling an entry ensure that the application does not use the corresponding technology. |
rules | Rules are added automatically by vWAF when you run the Baseline Protection Wizard or when you enable additional options for categories and tags. If a request matches one of the rules, vWAF denies the request with the specified error code. You can enable and disable rules and view rule details. However, you are not able to change individual parameters. To view rule details, click the arrow icon. To enable/disable a rule, click the traffic light symbol to toggle the status. A green light indicates the rule is enabled, a red light indicates the rule is disabled. vWAF only checks requests for the patterns of enabled rules. You can view and if applicable reset the inheritance for each rule. Rules are configured by the Baseline Protection Wizard. However, it is possible to disable rules individually using the Baseline Protection Handler. If a rule is disabled using the Handler, the rule inheritance state changes from Inherited to Local. If your web application does not use a particular technology, you can use the tags attribute to remove all rules that are specific the particular technology. This is more efficient than disabling rules individually. Similarly, if your web application is not vulnerable to particular kind of attack, you can use the categories attribute to remove the corresponding rules. |
error code | Defines the HTTP error code that vWAF returns when a request matches one of the patterns specified by the rules. (For an overview of possible error codes, see HTTP Error Codes.) |
usertext | Optional: You can specify text to be appended to log file entries created by this handler. For example, you could provide a brief description explaining how this handler is utilized in your deployment. |
enable logging | Disable this option if you do not require vWAF to create a log file entry each time the handler is executed. This may be appropriate, in detection mode, if you are concerned about the number and size of log files or you do not need to log entries by this handler. When in detection mode, disabling logging makes the handler ineffective. Disabling logging also prevents the actions of the handler from being considered as candidates for the Top-10 lists in Attack Analysis, and from being listed in Reports. To decrease the size of the log files, you can enable reduced logging, which excludes all non-handler-related information from the log files (see Editing Applications ). |
For details regarding entries added to the log file by this handler, see the relevant section in Entries in Application-Specific Log Files.