Available rule types

Manage request parsers

The rule Disable/Enable request parser allows you to manage the set of parsers applied to the request during its analysis.

By default, when analyzing the request, the WAF node attempts to apply each suitable parser to each request element sequentially. However, certain parsers can be applied mistakenly, causing the WAF node to detect (false) attack signs in the decoded value.

For instance, the WAF node might incorrectly interpret unencoded data as being encoded into Base64, given that Base64 alphabet symbols are frequently found in regular text, token values, UUID values, and other data formats. If the WAF node decodes the unencoded data and identifies signs of attack in the resulting value, a false positive is registered.

To avoid such false positives, the Disable/Enable request parser rule can be used to turn off parsers that are incorrectly used on certain request elements.

Create and apply rules

The rule can be both created and applied within the Attacks and Rules WAF sections.

• In the Attacks section, rules are generated with a pre-existing description of the endpoints where the rule will be applied. This description aligns with the request for which you've clicked the Rule button. To finalize the rule setup, choose the rule's action type and ensure all elements of the rule are set up correctly.
• In the Rules section, you'll need to manually input all components of the rule.

To create and apply the rule in the Rules section:

1. Create the rule Disable/Enable request parser in the Rules WAF section. The rule consists of the following components:

• The condition, describing the endpoints where the rule will be applied.
• Parsers that should be enabled or disabled for the specific request element.
• The part of the request refers to the original request element that should be parsed or left unparsed with the selected parsers. If multiple options are chosen sequentially in this part of the request, they should represent the order of parsers that the WAF would use to read the necessary request element.

2. Wait for the rule creation to be completed.

Rule example

Suppose the requests to https://example.com/users/ necessitate the authentication header X-AUTHTOKEN. The header value might include specific combinations of symbols (like '=' at the end) that WAF could potentially decode using the Base64 parser.

You can configure the Disable/Enable request parser rule to prevent false positives in the USER-AGENT values as follows:

Rules for data masking

The WAF node transmits the following information to the WAF cloud:

• Serialized requests with detected attacks
• WAF system counters
• System statistics such as CPU load and RAM usage
• WAF system statistics, including the number of processed nginx requests and Tarantool statistics
• Data about the type of traffic that WAF requires to accurately identify the application structure

Certain information should not be sent outside of the server where it is processed. This generally includes authorization details (like cookies, tokens, and passwords,) personal data, and payment information.

The WAF node can mask data in requests. Using this rule, the original value of the specified request point is removed before the request is sent to the postanalytics module and the WAF Cloud. This approach ensures that sensitive data does not unintentionally leave the secure environment.

This rule can impact the visibility of attacks, the verification of active threats, and the identification of brute-force attacks.

Masking of a cookie value

Here's an illustration of such rule creation. First, use the instructions above. The rule applies if the following conditions are specified in the If section:

• The application is accessible at the domain example.com
• The application uses a PHPSESSID cookie for user authentication
• Security policies deny access to this information for employees using WAF

To create a data masking rule for this cookie, the following actions should be performed in the Then section:

1. Go to the Rules tab.

2. Find the branch for example.com/**/*.* and click Add rule.

3. Choose Mask sensitive data.

4. Select the Header parameter and enter its value COOKIE. Select the cookie parameter and enter its value PHPSESSID after in this part of request. Options sequentially selected (if several) in this part of the request should reflect a sequence of parsers that WAF would apply to read the required request element.

5. Click Create.

User-defined detection rules

In certain situations, it's beneficial to add a signature for attack detection manually or create a virtual patch. While WAF doesn't employ regular expressions for attack detection, it does permit users to supplement with additional signatures that are based on regular expressions.

Add a new detection rule

Click the Create regexp-based attack indicator rule and fill in the fields:

• Regular expression: This is the signature used. If the value of the subsequent parameter aligns with the expression, the request is identified as an attack. The syntax and specifics of regular expressions are detailed in the instructions for adding rules.

• Changing the regular expression specified in the rule: If you alter the regular expression in an existing Create regexp-based attack indicator rule, any Disable regexp-based attack detection rules using the previous expression will be deleted automatically.

Note: To disable attack detection by a new regular expression, create a new Disable regexp-based attack detection rule specifying the new regular expression.

• Experimental: Test the trigger of a regular expression securely without blocking requests. Even when the filter node is in blocking mode, requests won't be blocked. These requests will be viewed as attacks detected via the experimental method and will be hidden from the event list by default. They can be found using the search query experimental attacks.

• Attack: The type of attack that will be detected when the parameter value in the request matches the regular expression.

• in this part of request: Determines the point in the request where the system should detect corresponding attacks. If multiple options are selected sequentially in in this part of the request, they should represent the order of parsers that WAF would use to read the necessary request element.

Blocking all requests with an incorrect user-agent header

Here's an illustration of such a rule. The rule applies if the following conditions are specified in the If section:

• The application is accessible at the domain example.com
• The application uses the USER-AGENT header

To create a rule for rejecting incorrect format tokens, specify the following in the Then section:

1. Go to the Rules tab.

2. Find the branch for example.com/**/*.* and click Add rule.

3. Select Define as an attack on the basis of a regular expression.

4. Set Regex value as ^Malicious-Actor$.

5. Choose Virtual patch as the attack type.

6. Set the USER-AGENT header.

7. Click Create.

Ignore certain attack types

The rule Ignore certain attack types allows you to disable the detection of specific types of attacks in certain request elements.

By default, if the WAF node detects signs of any type of attack in any element of a request, it labels the request as an attack. However, some requests that contain signs of attacks are actually legitimate. For instance, a request to publish a post on a database administrator forum might contain a description of a malicious SQL command, but it's not an attack.

If the WAF node mistakenly identifies a standard request payload as malicious, a false positive is registered. To avoid such false positives, customize standard attack detection rules by adding custom rules. The Ignore certain attack types rule is an example of such a custom rule.

Here's an illustration of such rule creation. First, use the instructions above.

Let's consider an example where a user confirms the publication of a post on a database administrator forum. The client sends a POST request to the endpoint https://example.com/posts/. This request has specific properties:

• The content of the post is transmitted in the request body parameter postBody. This content may incorporate SQL commands that WAF could potentially flag as malicious.
• The request body is of the application/json type.

Here's an example of a cURL request containing an SQL injection:

      Copy
      
    curl -H "Content-Type: application/json" -X POST https://example.com/posts -d '{"emailAddress":"johnsmith@example.com", "postHeader":"SQL injections", "postBody":"My post describes the following SQL injection: ?id=1%20select%20version();"}'

To disregard SQL injections in the postBody parameter of the requests to https://example.com/posts/, the Ignore certain attack types rule can be configured in the following way:

Ignoring attack signs in the binary data

The rules Allow binary data and Allow certain file types are used to adjust the standard attack detection rules for binary data.

By default, the WAF node analyzes incoming requests for all known attack signs. During the analysis, the WAF node may not consider the attack signs to be regular binary symbols and therefore may mistakenly detect malicious payloads in the binary data.

• The rule Allow binary data allows you to fine-tune attack detection for request elements containing binary data (e.g. archived or encrypted files.)
• The rule Allow certain file types allows you to fine-tune attack detection for request elements containing specific file types (e.g. PDF, JPG.)

To adjust the attack detection rules for the binary data passed in the specified request elements, create the rule Allow binary data in the Rules WAF section.

The rule consists of the following components:

• Condition describes the endpoints to which the rule is applied.
• Part of request points to the original request element containing the binary data.
• Options refers to the sequence of parsers (if multiple) that WAF should apply to read the required request element as selected in this part of the request.

To adjust the attack detection rules for certain file types passed in the specified request element, create the rule Allow certain file types in the Rules WAF section. The rule consists of the following components:

• Condition describes the endpoints to which the rule is applied.
• File types specifies the formats in which to ignore the signs of attack.
• Part of request points to the original request element containing the binary data.
• Options refers to the sequence of parsers (if multiple) that WAF should apply to read the required request element as selected in this part of the request.

Let's consider an example where a user uploads a binary file containing an image using a form on a website. The client sends a POST request of the type multipart/form-data to https://example.com/uploads/. The binary file is included in the body parameter fileContents.

The Allow binary data rule, which fine-tunes attack detection in the fileContents parameter, is configured as follows: